On 09/30/2014 02:51 PM, Kevin Grittner wrote:
> Josh Berkus <j...@agliodbs.com> wrote:
>> On 09/30/2014 02:39 PM, Kevin Grittner wrote:
>>> Josh Berkus <j...@agliodbs.com> wrote:
>>>> On 09/30/2014 07:15 AM, Kevin Grittner wrote:
>>>>> At the risk of pushing people away from this POV, I'll point out
>>>>> that this is somewhat similar to what we do for unlogged bulk loads
>>>>> -- if all the conditions for doing it the fast way are present, we
>>>>> do it the fast way; otherwise it still works, but slower.
>>>> Except that switching between fast/slow bulk loads affects *only* the
>>>> speed of loading, not the locking rules.  Having a statement silently
>>>> take a full table lock when we were expecting it to be concurrent
>>>> (because, for example, the index got rebuilt and someone forgot the
>>>> UNIQUE) violates POLA from my perspective.
>>> I would not think that an approach which took a full table lock to
>>> implement the more general case would be accepted.
>> Why not?  There are certainly cases ... like bulk loading ... where
>> users would find it completely acceptable.  Imagine that you're merging
>> 3 files into a single unlogged table before processing them into
>> finished data.
> So the expectation is that when we implement MERGE it will, by
> default, take out an EXCLUSIVE lock for the entire target table for
> the entire duration of the command?  I would have expected a bit
> more finesse.

I don't know that that is the *expectation*.  However, I personally
would find it *acceptable* if it meant that we could get efficient merge
semantics on other aspects of the syntax, since my primary use for MERGE
is bulk loading.

Regardless, I don't think there's any theoretical way to support UPSERT
without a unique constraint.  Therefore eventual support of this would
require a full table lock.  Therefore having it use the same command as
UPSERT with a unique constraint is a bit of a booby trap for users.
This is a lot like the "ADD COLUMN with a default rewrites the whole
table" booby trap which hundreds of our users complain about every
month.  We don't want to add more such unexpected consequences for users.

Josh Berkus
PostgreSQL Experts Inc.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to