On 10/01/2014 11:49 AM, Andres Freund wrote:
> On 2014-10-01 01:44:04 -0700, Peter Geoghegan wrote:
>> In the hope of unblocking things, I have created this Wiki page, which
>> details the advantages and disadvantages of all 3 approaches that have
>> been discussed, as suggested by myself and others:
>>
>> https://wiki.postgresql.org/wiki/Value_locking
Thank! That's a good summary.
>> This is by no means complete yet. There is pretty limited handling of
>> what I call "#3. "Promise" index tuples", because there was no
>> prototype version of that design, and there are many open questions
>> about how it would be implemented relative to the other 2 approaches.
>> Perhaps Andres or Simon would care to improve it. I think I've done a
>> better job of describing #2, Heikki's design - hardly surprising,
>> since there was a prototype that we discussed at length - but I'd
>> appreciate it if other people would make sure that I have everything
>> right there. This is hopefully the beginning of working the issues
>> out. I have of course also described my own proposed design alongside
>> the others.
>
> FWIW, Heikki's approach isn't what I'd have choosen, but it's something
> I can live with.
I didn't realize that "promise index tuples" were even seriously
discussed. I guess that can be made to work, too, although I don't see
the point. It wouldn't work with GiST indexes, for the same reasons as
page-level locking won't work (a tuple can legally be inserted anywhere
in a GiST index - it just degrades the index making searching more
expensive). And lossy GiST opclasses are a problem too.
It's actually more similar to approach #1 in that it puts the
responsibility of the locking in the indexam. You would probably need
the same kind of API changes to the indexam, and you could well imagine
one indexam to implement index promise tuples, while another one might
use heavy-weight locks. I don't see the advantage of #3.
- Heikki