Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"
От | Fabien COELHO |
---|---|
Тема | Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*" |
Дата | |
Msg-id | alpine.DEB.2.10.1407201435230.16752@sto обсуждение исходный текст |
Ответ на | Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*" (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: pg_stat_statements cluttered with "DEALLOCATE dbdpg_p*"
|
Список | 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 по дате отправления: