Re: On-demand running query plans using auto_explain and signals
От | Pavel Stehule |
---|---|
Тема | Re: On-demand running query plans using auto_explain and signals |
Дата | |
Msg-id | CAFj8pRBhdv6N4yRfJBd-JjYnfM89c4nshJEDyzxGVTWOCwy6vw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: On-demand running query plans using auto_explain and signals (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: On-demand running query plans using auto_explain and
signals
|
Список | pgsql-hackers |
2015-10-15 15:42 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
"Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de> writes:
> I was thinking about this and what seems to be the biggest problem is when
> to actually turn the feature on. It seems unlikely that someone will want
> to enable it unconditionally. Enabling per-backend also doesn't seem to be
> a good approach because you don't know if the next query you'd like to look
> at is going to run in this exact backend.
Check.
> What might be actually usable is poking pg_stat_statements for queryid to
> decide if we need to do explain (and possibly analyze).
Hm, interesting thought.
> Does this make sense to you? Does this make a good argument for merging
> pg_stat_statements and auto_explain into core?
I'd say more that it's a good argument for moving this feature out to
one of those extensions, or perhaps building a third extension that
depends on both of those. TBH, none of this stuff smells to me like
something that ought to be in core.
There are few features, that I would to see in core:
1. possibility to get full SQL string
2. possibility to get state string
We can speak how to do it well.
Regards
Pavel
regards, tom lane
В списке pgsql-hackers по дате отправления: