On 24 May 2012 22:57, Bruce Momjian <br...@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 be charged to the * underlying PREPARE instead (by the Executor hooks), which is much more * useful. * * We also don't track execution of PREPARE. If we did, we would get one * hash table entry for the PREPARE (with hash calculated from the query * string), and then a different one with the same query string (but hash * calculated from the query tree) would be used to accumulate costs of * ensuing EXECUTEs. This would be confusing, and inconsistent with other * cases where planning 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
