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

From Fabien COELHO
Subject Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"
Date
Msg-id alpine.DEB.2.10.1407201435230.16752@sto
Whole thread Raw
In response to Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"
List pgsql-hackers
Hello Andres,

> 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

Thanks for the advice. I'm not responsible for the application nor the 
driver, and I think that pg_stat_statements should be consistent and 
reasonable independently of drivers and applications.

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

(1) I'm not responsible for DBD::Pg allocating "random" names to prepared 
statements, even if the queries are the same, and that accumulate over 
time (weeks, possibly months).

(2) pg_stat_statements is currently inconsistent anyway, as PREPARE is not 
counted (but the underlying query is on each EXECUTE), although its 
corresponding DEALLOCATE is counted, so I think that something is needed 
for consistency.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Marko Tiikkaja
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*"