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
