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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <peter@2ndquadrant.com>
Cc: Daniel Farina <daniel@heroku.com>, Robert Haas <robertmhaas@gmail.com>, PG Hackers <pgsql-hackers@postgresql.org>
Date: 2012-03-28T14:25:26Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.

  2. Extend the parser location infrastructure to include a location field in

  3. Teach eval_const_expressions() to simplify an ArrayCoerceExpr to a constant

Peter Geoghegan <peter@2ndquadrant.com> writes:
> I merged upstream changes with the intention of providing a new patch
> for you to review. I found a problem that I'd guess was introduced by
> commit 9dbf2b7d75de5af38d087cbe2b1147dd0fd10f0a, "Restructure SELECT
> INTO's parsetree representation into CreateTableAsStmt". This has
> nothing to do with my patch in particular.

Yeah, I already deleted the intoClause chunk from the patch.  I think
treating SELECT INTO as a utility statement is probably fine, at least
for now.

> In the existing pg_stat_statements code in HEAD, there are 2
> pgss_store call sites - one in pgss_ProcessUtility, and the other in
> pgss_ExecutorFinish. There is an implicit assumption in the extant
> code (and my patch too) that there will be exactly one pgss_store call
> per query execution. However, that assumption appears to now fall
> down, as illustrated by the GDB session below. What's more, our new
> hook is called twice, which is arguably redundant.

That's been an issue right along for cases such as EXPLAIN and EXECUTE,
I believe.  Perhaps the right thing is to consider such executor calls
as nested statements --- that is, the ProcessUtility hook ought to
bump the nesting depth too.

			regards, tom lane