Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Mar 28, 2012 at 10:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The SELECT INTO tests all fail, but we know the reason why (the testbed
>> isn't expecting them to result in creating separate entries for the
>> utility statement and the underlying plannable SELECT).
> This might be a dumb idea, but for a quick hack, could we just rig
> SELECT INTO, CREATE TABLE AS, and EXPLAIN not to create entries for
> themselves at all, without suppressing creation of an entry for the
> underlying query?
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.
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.
This looks like it would work for the SELECT INTO and EXPLAIN cases,
and for DECLARE CURSOR whenever that gets changed to a less bizarre
structure. It would not work for EXECUTE, because in that case we
pass the query string saved from PREPARE to the executor. However,
we could possibly do a special-case hack for EXECUTE; maybe ask
prepare.c for the statement's string and stack that instead of the
outer EXECUTE query string.
Thoughts?
regards, tom lane
