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

On 22 March 2012 17:19, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'm inclined to think that the most useful behavior is to teach the
> rewriter to copy queryId from the original query into all the Queries
> generated by rewrite.  Then, all rules fired by a source query would
> be lumped into that query for tracking purposes.  This might not be
> the ideal behavior either, but I don't see a better solution.

+1. This behaviour seems fairly sane. The lumping together of DO ALSO
and DO INSTEAD operations was a simple oversight.

> This seems to boil down to what you want to have happen with queries
> created/executed inside functions, which is something I don't recall
> being discussed.

Uh, well, pg_stat_statements is clearly supposed to monitor execution
of queries from within functions - there is a GUC,
"pg_stat_statements.track", which can be set to 'all' to track nested
queries. That being the case, we should clearly be fingerprinting
those query trees too.

The fact that we'll fingerprint these queries even though we usually
don't care about them doesn't seem like a problem, since in practice
the vast majority will be prepared.

> Either way, I think we'd be a lot better advised to define a single
> hook "post_parse_analysis_hook" and make the core code responsible
> for calling it at the appropriate places, rather than supposing that
> the contrib module knows exactly which core functions ought to be
> the places to do it.

I agree.

Since you haven't mentioned the removal of parse-analysis Const
location alterations, I take it that you do not object to that, which
is something I'm glad of.

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