Horton

Re: why do we need two snapshots per query?

Simon Riggs <simon@2ndquadrant.com>

View thread
From: Simon Riggs <simon@2ndQuadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-11-13T16:31:31Z
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. Fix copyright notices, other minor editing in new range-types code.

  2. Redesign the plancache mechanism for more flexibility and efficiency.

On Sun, Nov 13, 2011 at 4:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> As far as partitioning goes, the correct solution there
> is to move the partition selection to run-time, so we should not be
> contorting query semantics to make incremental performance improvements
> with the existing partitioning infrastructure.

Agreed, but I think we need both planning and execution time
awareness, just as we do with indexonly.

That's what I'd like to be able to do: link planning and execution.

It's all very well to refuse individual cases where linkage is
required, but ISTM clear that there are many possible uses of being
able to tell whether a plan is one-shot or not and nothing lost by
allowing that information (a boolean) pass to the executor.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services