Re: INSERT...ON DUPLICATE KEY IGNORE

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: INSERT...ON DUPLICATE KEY IGNORE
Date: 2013-09-05 00:47:22
Message-ID: CAM3SWZQVJg_bJA9B-G93VoVezH07FEqx8BcqzrXM1JUggAqBpA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 4, 2013 at 5:08 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> I don't want "my" idea to win, I want a idea to win.

I know. I want the same thing.

> You're the patch author here whose plans are laid open to be scrutinized ;). If you think my idea has merit, use and adapt it to reality. If not, find another, better, solution.

Sure.

> Even if our path to that goal is confrontational at times, the goal is to find a good solution, not the argument itself.

Agreed.

> I haven't argued about INSERT ... DUPLICATE LOCK because the page locking scheme doesn't seem to work out for plain DUPLICATE. No need to think/argue about the fancier version in that case.

I see where you're coming from, but my point is precisely that adding
a row locking component *isn't* fancier. I've come to realize that
it's an integral part of the patch, and that my previous omission of
row locking - and the subsequent defence of that decision I made in
passing - was ridiculous. In a world where IGNORE/not locking is a
feature we support, it can only exist as an adjunct to ON DUPLICATE
KEY LOCK - certainly not the other way around.

The tail cannot be allowed to wag the dog.

In posting the patch with a row locking component, I'll only be asking
you to consider that aspect separately. You may find that seeing the
problems I encounter and how I handle them will make you (or others)
re-assess your thoughts on value locking in a direction that nobody
expects right now. Equally, I myself may reassess things.

Now, I don't guarantee that that's the case, but it certainly seems
very possible. And so even if I were to concede right now that the
buffer locking approach is not workable, I feel it would be a little
premature to seriously get down to talking about the alternatives in
detail.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-09-05 01:01:54 Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Previous Message Andres Freund 2013-09-05 00:08:48 Re: INSERT...ON DUPLICATE KEY IGNORE