Re: [HACKERS] MERGE SQL Statement for PG11
От | Peter Geoghegan |
---|---|
Тема | Re: [HACKERS] MERGE SQL Statement for PG11 |
Дата | |
Msg-id | CAH2-Wzkb0+k3E1J9YGetZHxHXNZMo_R-07rXb4FOwXRdcWD1HA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] MERGE SQL Statement for PG11 (Simon Riggs <simon@2ndquadrant.com>) |
Список | pgsql-hackers |
On Thu, Mar 22, 2018 at 12:59 AM, Simon Riggs <simon@2ndquadrant.com> wrote: >> The point here is that we're primarily talking about two whole tables. >> That deserves such prominent placement, as that suggests where users >> might really find MERGE useful, but without being too prescriptive. > > The information I have is that many people are expecting MERGE to work > for OLTP since that is how it is used in other databases, not solely > as an ETL command. I'm sure that that's true, which is why I said "...without being too prescriptive". > So we're not primarily talking about two whole tables. Sure, but that's where MERGE is going to be compelling. Especially for Postgres, which already has ON CONFLICT DO UPDATE. >> Also, instead of saying "There are a variety of differences and >> restrictions between the two statement types [MERGE and INSERT ... ON >> CONFLICT DO UPDATE] and they are not interchangeable", you could >> instead be specific, and say: >> >> MERGE is well suited to synchronizing two tables using multiple >> complex conditions. Using INSERT with ON CONFLICT DO UPDATE works well >> when requirements are simpler. Only ON CONFLICT provides an atomic >> INSERT or UPDATE outcome in READ COMMITTED mode. >> >> BTW, the docs should be clear on the fact that "INSERT ... ON >> CONFLICT" isn't a statement. INSERT is. ON CONFLICT is a clause. > > I think it would be better if you wrote a separate additional doc > patch to explain all of this, perhaps in Performance Tips section or > otherwise. I don't think that it has much to do with performance. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: