On Thu, Mar 29, 2012 at 11:42 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Mar 29, 2012 at 11:23 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> 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. > > What do you object to --- the pointer-equality part? We could do strcmp > comparison instead, on the assumption that a utility command could not > look the same as an optimizable statement except in the case we care > about. I think that's probably unnecessary though.
The pointer equality part seems like the worst ugliness, yes. >> Can't we find a way to set the stacked flag (on the top stack frame) >> after planning and before execution? > > That would require a way for pg_stat_statements to get control at rather > random places in several different types of utility statements. And > if we did add hook functions in those places, you'd still need to have > sufficient stacked context for those hooks to know what to do, which > leads you right back to this I think. What I'm imagining is that instead of just having a global for nested_level, you'd have a global variable pointing to a linked list. The length of the list would be equal to what we currently call nested_level + 1. Something like this: struct pgss_nesting_info { struct pgss_nesting_info *next; int flag; /* bad name */ }; static pgss_nesting_info *pgss_stack_top; So any test for nesting_depth == 0 would instead test pgss_stack_top->next != NULL. Then, when you get control at the relevant spots, you set pgss_stack_top->flag = 1 and that's it. Now, maybe it's too ugly to think about passing control at those spots; I'm surprised there's not a central point they all go through... Another thought is: if we simply treated these as nested queries for all purposes, would that really be so bad? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers