Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On 01/14/2014 11:22 PM, Peter Geoghegan wrote:
> On Tue, Jan 14, 2014 at 2:43 AM, Heikki Linnakangas
> <hlinnakangas@vmware.com> wrote:
>> You have suspected that many times throughout this thread, and every time
>> there's been a relatively simple solutions to the issues you've raised. I
>> suspect that's also going to be true for whatever mundane next issue you
>> come up with.
>
> I don't think it's a mundane issue. But in any case, you haven't
> addressed why you think your proposal is more or less better than my
> proposal, which is the pertinent question.

1. It's simpler.

2. Works for exclusion constraints.

> You haven't given me so
> much as a high level summary of whatever misgivings you may have about
> it, even though I've asked you to comment on my approach to value
> locking several times. You haven't pointed out that it has any
> specific bug (which is not to suppose that that's because there are
> none). The point is that it is not my contention that what you're
> proposing is totally unworkable. Rather, I think that the original
> proposal will probably ultimately perform better in all cases, is
> easier to reason about and is certainly far more modular. It appears
> to me to be the more conservative of the two proposals. In all
> sincerity, I simply don't know what factors you're weighing here. In
> saying that, I really don't mean to imply that you're assigning weight
> to things in a way that I am in disagreement with. I simply don't
> understand what is important to you here, and why your proposal
> preserves or enhances the things that you believe are important. Would
> you please explain your position along those lines?

I guess that simplicity is in the eye of the beholder, but please take a 
look at git diff --stat:
 41 files changed, 1224 insertions(+), 107 deletions(-)

vs.
 50 files changed, 2215 insertions(+), 240 deletions(-)

Admittedly, some of the difference comes from the fact that you've spent 
a lot more time commenting and polishing the btreelock patch. But mostly 
I dislike additional complexity required in b-tree for this.

I don't think B-tree locking is more conservative. The 
insert-and-then-check approach is already used by exclusion constraints, 
I'm just extending it to not abort on conflict, but do something else.

- Heikki