Re: someone working to add merge?

OK, I'm relatively new on this list, and I might have missed a few
discussions on this topic.
I wonder if doing it this way would not be better than using a table
lock:

- set a save point;
- insert the row;
- on error:
- roll back to the save point;
- update the row;
- on success release the save point;

This would provide less contention while paying the prise for the save
point. In low contention scenarios the table lock would be better, and I
wonder for high contention scenarios which is better, the table lock, or
the save point version...

Of course the table lock version is the future if predicate locking is
going to be implemented later.

Cheers,
Csaba.

On Fri, 2005-11-11 at 18:37, Peter Eisentraut wrote:
> Josh Berkus wrote:
> > Funny, we were just discussing this at OpenDBCon. Seems that you
> > can't do a full implementation of MERGE without Predicate Locking
> > (the ability to say "lock this table against inserts or updates of
> > any row with key=5"). However, Peter suggested that we could do a
> > proof-of-concept implementation, working out syntax and trigger
> > issues, based on a full table lock and do the hard work once it was
> > proved to be feasable.
>
> Yes, I've started to work on this. Realizing that the current way to
> manually do an UPDATE-else-INSERT or DELETE-then-INSERT involves a
> table lock anyway, a MERGE implementation using a table lock would at
> least give some convenience benefit to users. (And possibly some
> performance, too, if the decision logic is currently run in the
> client.)
>
> A predicate locking implementation for MERGE might actually not be all
> that complicated, because you only need to look on pk = constant, not
> on arbitrary expressions. Nevertheless, I think it's best to write the
> MERGE command first and then optimize the locking.