David Fetter wrote:
> I think I haven't communicated clearly what I'm suggesting, which is
> that we ship with both an UPSERT and a MERGE, the former being ugly,
> crude and simple, and the latter festooned with dire warnings about
> isolation levels and locking.
>
I don't know that I completely agree with the idea that the UPSERT
version should always be crude and the MERGE one necessarily heavy from
a performance perspective. However, I do feel you raise a legitimate
point that once the hard stuff is done, and the locking issues around
SQL proper MERGE sorted, having an UPSERT/REPLACE synonym that maps to
it under the hood may be a useful way to provide a better user
experience. The way I see this, the right goal is to first provide the
full spec behavior with good performance, and get all that plumbing
right. There's nothing that says we can't provide an easier syntax than
the admittedly complicated MERGE one to the users though. (I am tempted
to make a joke about how you could probaby
So, as for this patch...there's about half a dozen significant open
issues with the current code, along with a smattering of smaller ones.
The problems remaining are deep enough that I think it would be
challenging to work through them for this CF under the best conditions.
And given that we haven't heard from Boxuan since early December, we're
definitely understaffed to tackle major revisions.
My hope was that we'd get an updated patch from him before the CF
deadline. Even without it, maybe get some more internal help here.
Given my focus on checkpoint issues, Simon on Sync Rep, and Dimitri
still on his Extensions push, that's second part isn't going to happen.
I am marking MERGE officially "Returned With Feedback" for 9.1. Lots of
progress made, much better community understanding of the unresolved
issues now than when we started, but not in shape to go into this
release. Since we still have some significant interest here in getting
this finished, I'll see if I can get put together a better game-plan for
how to get this actually done for 9.2 in time to discuss at release
planning time. The main thing that's become much more obvious to me
just recently is how the remaining issues left here relate to the true
serialization work, so worrying about that first is probably the right
order anyway.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
