On 24 May 2012 22:57, Bruce Momjian <bruce@momjian.us> wrote:
> OK, item moved down. We have not have "bug fix" designation. You have
> a suggestion?
I assumed you were going to put it beside the other compatibility note
relating to pg_stat_statements, "Change pg_stat_statements' total_time
column to be measured in milliseconds (Tom Lane)".
The "Improve pg_stat_statements' handling of PREPARE/EXECUTE
statements" is just a way of preventing SQL PREPARE and EXECUTE
utility statements from being double counted in various ways as both
utility statements and optimisable statements. No one actually noticed
this before, and it wouldn't have been feasible to fix in back
branches, I think. Here are the relevant comments:
* If it's an EXECUTE statement, we don't track it and don't increment * the nesting level. This allows the cycles to
becharged to the * underlying PREPARE instead (by the Executor hooks), which is much more * useful. * * We also don't
trackexecution of PREPARE. If we did, we would get one * hash table entry for the PREPARE (with hash calculated from
thequery * string), and then a different one with the same query string (but hash * calculated from the query tree)
wouldbe used to accumulate costs of * ensuing EXECUTEs. This would be confusing, and inconsistent with other * cases
whereplanning time is not included at all.
Also, as I've said, this I/O timings thing certainly deserves to be
separately listed as a new pg_stat_statements feature:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5b4f346611431361339253203d486789e4babb02
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services