Re: On-demand running query plans using auto_explain and signals
| От | Tom Lane |
|---|---|
| Тема | Re: On-demand running query plans using auto_explain and signals |
| Дата | |
| Msg-id | 32603.1444916567@sss.pgh.pa.us обсуждение |
| Ответ на | Re: On-demand running query plans using auto_explain and signals ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>) |
| Ответы |
Re: On-demand running query plans using auto_explain and signals
|
| Список | pgsql-hackers |
"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.
regards, tom lane
В списке pgsql-hackers по дате отправления: