Prev: patch: Add JSON datatype to PostgreSQL (GSoC, WIP)
Next: [HACKERS] reminder... beta4 is coming
From: Tom Lane on 4 Aug 2010 14:45
Marko Tiikkaja <marko.tiikkaja(a)cs.helsinki.fi> writes:
> According to the latter commit, not updating the snapshot could be
> preferable for EXPLAIN ANALYZE, but I don't see why this is. Maybe we
> should wait until we hear from Tom?

Sorry for not catching up on my email sooner. On the whole I'm in
agreement with the argument that wCTEs should *not* take whole new
snapshots between queries, but only advance the CID. The points
that sway me that way are:

1. To do otherwise will decrease the predictability of wCTE results.

2. The argument for taking a new snapshot seems to be mostly
"because that's what rules do"; but it's agreed that rules have a
lot of surprising and undesirable behavior, and it's not clear that
this isn't part of that.

3. In particular I don't agree with the argument that functions taking
new snapshots between queries should be a precedent for this. In
a function, the user thinks of the successive lines as separate queries,
and it's reasonable for them to act similarly to what would happen if
they were issued as separate top-level commands. I do not see that that
argument applies to wCTEs, which by definition are parts of a single
command.

In any case the behavior is going to have to be documented, but I vote
for advance-CID-only so far as wCTEs are concerned.

The other thing that was being argued was whether rules should be
changed to act that way too, and if not whether EXPLAIN ANALYZE should
be fixed to make sure it emulates rule execution better. Personally
I'd be in favor of changing rule execution and leaving EXPLAIN ANALYZE
alone, though I'm not sure if that position can command a consensus.
I seriously doubt that there are many applications out there that are
actually depending on this aspect of rule execution; if anything, there
are probably more that will see it as a bug.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 4 Aug 2010 15:26
On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> The other thing that was being argued was whether rules should be
> changed to act that way too, and if not whether EXPLAIN ANALYZE should
> be fixed to make sure it emulates rule execution better. �Personally
> I'd be in favor of changing rule execution and leaving EXPLAIN ANALYZE
> alone, though I'm not sure if that position can command a consensus.
> I seriously doubt that there are many applications out there that are
> actually depending on this aspect of rule execution; if anything, there
> are probably more that will see it as a bug.

Changing EXPLAIN ANALYZE seems a bit less likely to break things for
anyone depending on current behavior; but, on the other hand, it seems
there's a broad consensus that the best thing to do about rule
execution is deprecate it, so maybe it doesn't really matter.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Marko Tiikkaja on 4 Aug 2010 15:55
On 8/4/2010 10:26 PM, Robert Haas wrote:
> On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane<tgl(a)sss.pgh.pa.us> wrote:
>> The other thing that was being argued was whether rules should be
>> changed to act that way too, and if not whether EXPLAIN ANALYZE should
>> be fixed to make sure it emulates rule execution better. Personally
>> I'd be in favor of changing rule execution and leaving EXPLAIN ANALYZE
>> alone, though I'm not sure if that position can command a consensus.
>> I seriously doubt that there are many applications out there that are
>> actually depending on this aspect of rule execution; if anything, there
>> are probably more that will see it as a bug.
>
> Changing EXPLAIN ANALYZE seems a bit less likely to break things for
> anyone depending on current behavior; but, on the other hand, it seems
> there's a broad consensus that the best thing to do about rule
> execution is deprecate it, so maybe it doesn't really matter.

I'm having a hard time imagining that anyone would depend on a behaviour
like this.


Regards,
Marko Tiikkaja

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 4 Aug 2010 16:14
Robert Haas <robertmhaas(a)gmail.com> writes:
> On Wed, Aug 4, 2010 at 2:45 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
>> I seriously doubt that there are many applications out there that are
>> actually depending on this aspect of rule execution; if anything, there
>> are probably more that will see it as a bug.

> Changing EXPLAIN ANALYZE seems a bit less likely to break things for
> anyone depending on current behavior;

Well, the point I was trying to make is that there may well be fewer
people depending on the current behavior than there are people for whom
the current behavior is wrong, only they don't know it because they've
not seen a failure (or not seen one often enough to diagnose what's
happening).

This is of course merest speculation either way. But I don't feel that
we need to necessarily treat rule behavior as graven in stone.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: patch: Add JSON datatype to PostgreSQL (GSoC, WIP)
Next: [HACKERS] reminder... beta4 is coming