From: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PG10 transition tables, wCTEs and multiple operations on the same table |
Date: | 2017-06-07 21:19:08 |
Message-ID: | CACjxUsOVYnuejYk5bif5bRpr+39MiMgdC=ZjQejR9nbOp+OE1w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 7, 2017 at 3:42 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Wed, Jun 7, 2017 at 7:27 PM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> On Wed, Jun 7, 2017 at 10:47 AM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>>> I suppose you'll need two tuplestores for the ON CONFLICT DO UPDATE
>>> case -- one for updated tuples, and the other for inserted tuples.
>>
>> Hmm. Right. INSERT ... ON CONFLICT DO UPDATE causes both AFTER
>> INSERT and AFTER UPDATE statement-level triggers to be fired, but then
>> both kinds see all the tuples -- those that were inserted and those
>> that were updated. That's not right.
>
> Or maybe it is right.
The idea of transition tables is that you see all changes to the
target of a single statement in the form of delta relations -- with
and "old" table for any rows affected by a delete or update and a
"new" table for any rows affected by an update or delete. If we
have a single statement that combines INSERT and UPDATE behaviors,
it might make sense to have an "old" table for updates and a single
"new" table for both.
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2017-06-07 21:47:13 | Re: PG10 transition tables, wCTEs and multiple operations on the same table |
Previous Message | Alvaro Herrera | 2017-06-07 21:18:03 | Re: logical replication - possible remaining problem |