Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*" - Mailing list pgsql-hackers

From Andres Freund
Subject Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"
Date
Msg-id 20140720115401.GC24864@alap3.anarazel.de
Whole thread Raw
In response to pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses 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>)
List 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 by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"
Next
From: Andres Freund
Date:
Subject: Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"