Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"
Дата
Msg-id 20140720115401.GC24864@alap3.anarazel.de
обсуждение исходный текст
Ответ на pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы 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>)
Список pgsql-hackers
Hi,

On 2014-04-01 16:45:29 +0200, Fabien COELHO wrote:
> I noticed that my pg_stat_statements is cluttered with hundreds of entries
> like "DEALLOCATE dbdpg_p123456_7", occuring each only once.

Why isn't the driver using the extended query protocol? Sending
PREPARE/EXECUTE/DEALLOCATE wastes roundtrips...

> It seems to me that it would be more helful if these similar entries where
> aggregated together, that is if the query "normalization" could ignore the
> name of the descriptor.

I'm not in favor of this. If there's DEALLOCATEs that are frequent
enough to drown out other entries you should

a) Consider using the extended query protocol.
b) consider using unnamed prepared statements to reduce the number of  roundtrips
c) wonder why PREPARE/DEALLOCATE are so much more frequent than the  actualy query execution.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



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

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"
Следующее
От: Andres Freund
Дата:
Сообщение: Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"