Re: Buffer usage in EXPLAIN and pg_stat_statements (review) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Buffer usage in EXPLAIN and pg_stat_statements (review)
Date
Msg-id 603c8f070910141824w74b5a43bide8a7a5319aa841b@mail.gmail.com
Whole thread Raw
In response to Re: Buffer usage in EXPLAIN and pg_stat_statements (review)  (Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Responses Re: Buffer usage in EXPLAIN and pg_stat_statements (review)
EXPLAIN BUFFERS
List pgsql-hackers
2009/10/14 Itagaki Takahiro <itagaki.takahiro@oss.ntt.co.jp>:
>
> Robert Haas <robertmhaas@gmail.com> wrote:
>
>> > 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.
>>
>> 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.
>
> Ok, I'll reconsider them and re-submit patches for the next commitfest.
> Maybe I need to split the patch into EXPLAIN-part and contrib-part.

My (limited) experience is that it's usually better to get something
incremental committed, even if it's not what you really want.  You can
always take another crack at the remaining issues later, but if the
whole patch gets shot down then you are out of luck.

In this case, I think that the auto_explain changes out to be part of
the same patch as the core EXPLAIN changes, but if the
pg_stat_statement stuff is severable it might make sense to push that
off until later.

...Robert


pgsql-hackers by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: Reworks for Access Control facilities (r2363)
Next
From: KaiGai Kohei
Date:
Subject: Re: CommitFest 2009-09, two weeks on