Horton

Re: why do we need two snapshots per query?

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-11-13T16:09:52Z
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.

Simon Riggs <simon@2ndQuadrant.com> writes:
> If we could be certain that a query was being executed immediately

... that is, with the same snapshot ...

> then it would be possible to simplify expressions using stable
> functions as if they were constants. My earlier patch did exactly
> that.

Mph.  I had forgotten about that aspect of it.  I think that it's
very largely superseded by Marti Raudsepp's pending patch:
https://commitfest.postgresql.org/action/patch_view?id=649
which does more and doesn't require any assumption that plan and
execution snapshots are the same.

Now you're going to say that that doesn't help for failure to prove
partial index or constraint conditions involving stable functions,
and my answer is going to be that that isn't an interesting use-case.
Partial index conditions *must* be immutable, and constraint conditions
*should* be.  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.

I remain of the opinion that Robert's proposal is a bad idea.

			regards, tom lane