On Thu, Mar 29, 2012 at 11:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Mar 29, 2012 at 11:23 AM, Tom Lane <tgl@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
