Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"
Дата
Msg-id 10346.1405878962@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-07-20 17:01:50 +0200, Fabien COELHO wrote:
>> If you do not like my normalization hack (I do not like it much either:-), I
>> have suggested to add "&& !IsA(parsetree, DeallocateStmt)" to the condition
>> above, which would ignore DEALLOCATE as PREPARE and EXECUTE are currently
>> and rightfully ignored.

> Well, EXECUTE isn't actually ignored, but tracked via the execution
> time. But that doesn't diminish your point with PREPARE. If we do
> something we should go for the && !IsA(parsetree, DeallocateStmt), not
> the normalization. The latter is pretty darn bogus.

Agreed.  I think basically the reasoning here is "since we don't track
PREPARE or EXECUTE, we shouldn't track DEALLOCATE either".

However, this is certainly a behavioral change.  Perhaps squeeze it
into 9.4, but not the back braches?
        regards, tom lane



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

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: SQL MERGE is quite distinct from UPSERT
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"