Horton

Re: Draft release notes complete

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Peter Geoghegan <peter@2ndquadrant.com>
Cc: Josh Berkus <josh@agliodbs.com>, pgsql-hackers@postgresql.org
Date: 2012-05-24T23:11:20Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Expose track_iotiming information via pg_stat_statements.

  2. Rewrite GiST support code for rangetypes.

  3. Clean up a couple of box gist helper functions.

  4. Replace the "New Linear" GiST split algorithm for boxes and points with a

Attachments

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