Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Geoghegan <peter(at)2ndquadrant(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Date: 2012-03-29 15:42:10
Message-ID: 23523.1333035730@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

> 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shigeru HANADA 2012-03-29 15:46:03 Re: pgsql_fdw, FDW for PostgreSQL server
Previous Message Robert Haas 2012-03-29 15:34:54 Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)