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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Дата
Msg-id 23523.1333035730@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Список pgsql-hackers
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.

> 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Следующее
От: Shigeru HANADA
Дата:
Сообщение: Re: pgsql_fdw, FDW for PostgreSQL server