On Tue, May 23, 2006 at 03:50:01PM -0400, Alvaro Herrera wrote: > Tom Lane wrote: > > > Counting individual statements would add overhead (which the OP already > > declared unacceptable) and there are some definitional issues too, like > > whether to count statements executed within functions. > > Yeah, the problem seems underspecified. How do you count statements > added or removed by rewrite rules? Statements executed to answer RI > queries? Do you count the statements issued by clients as part of the > startup sequence? The hypothetical "reset session" of a connection pool > handler? How do you count 2PC -- when they are executed, or when they > are committed? What happens to statements in transactions that are > rolled back? What happens to a statement that is executed partially > because it failed partway (e.g. because of division by zero)? > > > OTOH ISTM it would be easy to modify Postgres so as to count statements > in the stat collector, by turning pgstat_report_activity into a routine > that sent a count (presumably always 1) instead of the query string, and > then just add the count to a counter on receiving. Yeah, I doubt any other database gets mired neck-deep in exact details of statment execution counts; a simple count of queries executed via a client connection would be a great start. I often run into situations where people are having a performance issue because they're building web pages that make 50 queries to the database. Being able to identify that and determine how many were selects vs. DML would be useful. Bonus points if there are seperate counters for statements from functions. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@xxxxxxxxxxxxx Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
