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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
