Hello, On 15/10/2015 16:04, Pavel Stehule wrote: > > > 2015-10-15 15:42 GMT+02:00 Tom Lane <t...@sss.pgh.pa.us > <mailto:t...@sss.pgh.pa.us>>: > > "Shulgin, Oleksandr" <oleksandr.shul...@zalando.de > <mailto:oleksandr.shul...@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. >
I registered as reviewer on this, but after reading the whole thread for the second time, it's still not clear to me if the last two submitted patches (0001-Add-auto_explain.publish_plans.patch and 0002-Add-SHM-table-of-contents-to-the-explain-DSM.patch) are still needed reviews, since multiple refactoring ideas and objections have been raised since. Regards. -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
