Re: Draft release notes complete

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. +