From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: How to share the result data of separated plan |
Date: | 2010-11-08 16:38:25 |
Message-ID: | 25871.1289234305@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Nov 7, 2010 at 1:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I guess I shoulda been paying closer attention :-(. That really, really
>> seems like fundamentally the wrong direction. What was it that was
>> unfixable about the other way? If it is unfixable, should we revert
>> ModifyTable?
> The relevant thread is here:
> http://archives.postgresql.org/pgsql-hackers/2010-02/msg00783.php
My opinion is still the same as here:
http://archives.postgresql.org/pgsql-hackers/2010-02/msg00688.php
namely, that all we should be worrying about is a tuplestore full of
RETURNING tuples. Any other side-effects of a DML subquery should
*not* be visible to the calling query, and therefore all this argument
about snapshots and seqscan limits is beside the point.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-11-08 16:45:53 | Re: How to share the result data of separated plan |
Previous Message | Tom Lane | 2010-11-08 16:32:12 | Re: Protecting against unexpected zero-pages: proposal |