Re: Buffer usage in EXPLAIN and pg_stat_statements (review)
От | Robert Haas |
---|---|
Тема | Re: Buffer usage in EXPLAIN and pg_stat_statements (review) |
Дата | |
Msg-id | 603c8f070910141746j781a79dfx93462ae2f155c50b@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Buffer usage in EXPLAIN and pg_stat_statements (review) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Buffer usage in EXPLAIN and pg_stat_statements (review)
|
Список | pgsql-hackers |
On Wed, Oct 14, 2009 at 9:56 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes: >> Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> 2. I do not understand the stuff with propagating counts into the top >>> instrumentation node. > >> It is required by contrib/pg_stat_statements. EXPLAIN wants per-node >> accumulation, but pg_stat_statements wants the total number. > > Well, you need to find another way or risk getting the patch rejected > altogether. Those global variables are the weakest part of the whole > design, and I'm not going to commit a patch that destabilizes the entire > system for the sake of a debatable "requirement" of a contrib module. > > If you went with the alternative definition I suggested (don't reset the > static counters, so that every node includes its children's counts) then > the behavior you want would fall out automatically. Or, at the price of > running both resettable and non-resettable static counters, you could > have pg_stat_statements obtain totals that are independent of any > particular instrumentation node. I am marking this patch as Returned with Feedback. I hope that it will be resubmitted for a future CommitFest, because I think this could be pretty interesting feature. ...Robert
В списке pgsql-hackers по дате отправления: