Jeff Davis <pgsql@j-davis.com> wrote:
> [discussion of a "pure" predicate locking scheme where each
> database modification is checked against a list of predicate
> expressions]
> My biggest worry is that a predicate locking scheme like this will
> be fairly difficult to implement and expensive to execute.
I couldn't agree more. I am not aware of any production-quality
database with predicate locking which has used such a "pure"
(purist?) implementation, and I have no ambition to attempt to be
first on this front. For a page-and-a-half summary (with references
to more exhaustive works) on the how I think predicate locking
should be done, see [1] -- in particular section:
6.5.3 Next-Key Locking: Physical Surrogates for Logical Properties
Some here seem to be missing the point, to various degrees, which I
am trying to make that the table, page, tuple, and index range locks
I'm proposing *are* forms of predicate locking. If after we have
locking working that way, people feel that there would be a net gain
to implement the "pure" form, it's open source -- if they can show
reasonable benchmarks that that works better, cool. Personally, I
think it's a nice abstract concept with zero chance of working well
on an industrial scale without some compromises with reality, such
as described in the referenced paper.
If anyone else wants to jump in and say it in different words, to
help get the idea across (since I seem to be doing it so poorly),
feel free to jump in.
-Kevin
[1] Joseph M. Hellerstein, Michael Stonebraker and James Hamilton.
2007. Architecture of a Database System. Foundations and Trends(R)
in Databases Vol. 1, No. 2 (2007) 141*259.
http://db.cs.berkeley.edu/papers/fntdb07-architecture.pdf
