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

I wrote:
> Hm ... I just had a different idea. I need to go look at the code
> again, but I believe that in the problematic cases, the post-analyze
> hook does not compute a queryId for the optimizable statement. This
> means that it will arrive at the executor with queryId zero. What if
> we simply made the executor hooks do nothing when queryId is zero?
> (Note that this also means that in the problematic cases, the behavior
> is already pretty wrong because executor costs for *all* statements of
> this sort are getting merged into one hashtable entry for hash zero.)

The attached proposed patch does it that way. It makes the EXPLAIN,
SELECT INTO, and DECLARE CURSOR cases behave as expected for utility
statements. PREPARE/EXECUTE work a bit funny though: if you have
track = all then you get EXECUTE cycles reported against both the
EXECUTE statement and the underlying PREPARE. This is because when
PREPARE calls parse_analyze_varparams the post-analyze hook doesn't know
that this isn't a top-level statement, so it marks the query with a
queryId. I don't see any way around that part without something like
what I suggested before. However, this behavior seems to me to be
considerably less of a POLA violation than the cases involving two
identical-looking entries for self-contained statements, and it might
even be thought to be a feature not a bug (since the PREPARE entry will
accumulate totals for all uses of the prepared statement). So I'm
satisfied with it for now.

regards, tom lane