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