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

On Thu, Mar 29, 2012 at 11:23 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> It would make more sense to me to go the other way, that is suppress
> creation of a separate entry for the contained optimizable statement.
> The stats will still be correctly accumulated into the surrounding
> statement (or at least, if they are not, that's a separate pre-existing
> bug).  If we do it in the direction you suggest, we'll fail to capture
> costs incurred outside execution of the contained statement.

All things being equal, I completely agree. However, ISTM that the
difficulty of implementation might be higher for your proposal, for
the reasons you go on to state. If getting it right means that other
significant features are not going to get committed at all for 9.2, I
think we could leave this as a TODO.

> Right now, we already have logic in there to track nesting of statements
> in a primitive way, that is just count the nesting depth.  My first idea
> about fixing this was to tweak that logic so that it stacks a flag
> saying "we're in a utility statement that contains an optimizable
> statement", and then the first layer of Executor hooks that sees that
> flag set would know to not do anything.  However this isn't quite good
> enough because that first layer might not be for the "same" statement.
> As an example, in an EXPLAIN ANALYZE the planner might pre-execute
> immutable or stable SQL functions before we reach the executor.  We
> would prefer that any statements embedded in such a function still be
> seen as independent nested statements.
>
> However, I think there is a solution for that, though it may sound a bit
> ugly.  Rather than just stacking a flag, let's stack the query source
> text pointer for the utility statement.  Then in the executor hooks,
> if that pointer is *pointer* equal (not strcmp equal) to the optimizable
> statement's source-text pointer, we know we are executing the "same"
> statement as the surrounding utility command, and we do nothing.

Without wishing to tick you off, that sounds both ugly and fragile.
Can't we find a way to set the stacked flag (on the top stack frame)
after planning and before execution?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company