Re: [HACKERS] PG10 transition tables, wCTEs and multiple operationson the same table
От | Kevin Grittner |
---|---|
Тема | Re: [HACKERS] PG10 transition tables, wCTEs and multiple operationson the same table |
Дата | |
Msg-id | CACjxUsOVYnuejYk5bif5bRpr+39MiMgdC=ZjQejR9nbOp+OE1w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] PG10 transition tables, wCTEs and multiple operationson the same table (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: [HACKERS] PG10 transition tables, wCTEs and multiple operationson the same table
Re: [HACKERS] PG10 transition tables, wCTEs and multiple operationson the same table |
Список | pgsql-hackers |
On Wed, Jun 7, 2017 at 3:42 AM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Wed, Jun 7, 2017 at 7:27 PM, Thomas Munro > <thomas.munro@enterprisedb.com> wrote: >> On Wed, Jun 7, 2017 at 10:47 AM, Peter Geoghegan <pg@bowt.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/
В списке pgsql-hackers по дате отправления: