On 22 March 2012 17:19, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers