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 по дате отправления: