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

Peter Geoghegan <peter(at)2ndquadrant(dot)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