On Thu, May 24, 2012 at 11:16:28PM +0100, Peter Geoghegan wrote:
> 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 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.
OK, I updated the wording on this, but don't see it as something
incompatibile, in the same way that the others listed are incompatible.
>
> 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
OK, I merged that into the existing item. Applied patch attached.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +