Robert Haas <robertmh...@gmail.com> writes: > On Wed, Mar 28, 2012 at 10:39 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers