On Thu, Mar 22, 2018 at 12:59 AM, Simon Riggs <si...@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
