Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

On 1 March 2012 22:09, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 3/1/12 1:57 PM, Daniel Farina wrote:
>> On Thu, Mar 1, 2012 at 1:27 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
>>> My expectation is that this feature will make life a lot
>>> easier for a lot of Postgres users.
>>
>> Yes.  It's hard to overstate the apparent utility of this feature in
>> the general category of visibility and profiling.
>
> More importantly, this is what pg_stat_statements *should* have been in
> 8.4, and wasn't.

It would probably be prudent to concentrate on getting the core
infrastructure committed first. That way, we at least know that if
this doesn't get into 9.2, we can work on getting it into 9.3 knowing
that once committed, people won't have to wait over a year at the very
least to be able to use the feature. The footprint of such a change is
quite small:

src/backend/nodes/copyfuncs.c | 2 +
src/backend/nodes/equalfuncs.c | 4 +
src/backend/nodes/outfuncs.c | 6 +
src/backend/nodes/readfuncs.c | 5 +
src/backend/optimizer/plan/planner.c | 1 +
src/backend/parser/analyze.c | 37 +-
src/backend/parser/parse_coerce.c | 12 +-
src/backend/parser/parse_param.c | 11 +-
src/include/nodes/parsenodes.h | 3 +
src/include/nodes/plannodes.h | 2 +
src/include/parser/analyze.h | 12 +
src/include/parser/parse_node.h | 3 +-

That said, I believe that the patch is pretty close to a commitable
state as things stand, and that all that is really needed is for a
committer familiar with the problem space to conclude the work started
by Daniel and others, adding:

contrib/pg_stat_statements/pg_stat_statements.c | 1420 ++++++++++++++++++-

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services