Jeff Davis <pgsql@j-davis.com> wrote:
> Consider an exclusion constraint, which is a kind of predicate
> lock. You could say that the lock is in the index (now) -- but my
> first implementation used a shared memory structure instead, so
> it's clearly not required to exist in the index. You could also
> say that the lock is really attached to the table, because there
> are catalog entries connected to the table that express the
> constraint -- but I think that's splitting hairs.
Well, we're starting by locking entire tables (as a very simple way
to get correctness), then reducing the granularity where we can find
a way to do that. I'll not exclusion constraints as an area needing
R&D. Thanks for pointing it out.
> What Greg is saying (as I understand it) is that the lock
> conflicts with tuples that don't even exist yet. We can tack them
> on to any structure that's convenient, of course. But just because
> you want to implement them by locking a few index pages (assuming
> there is an index) doesn't mean we should reject Greg's line of
> thinking.
As I understand it, Greg's line of thinking is that we should use a
technique which has never proven practical on a large scale:
matching database changes against a list of predicate lock
expressions. It's not that I want to do it any particular way, it's
that I want to get it working in the simplest possible way and then
find things which can be shown to improve overall performance of
meaningful work loads until we have something which has acceptable
performance. I don't reject "pure" predicate tracking, per se -- I
just won't put any time into it, since I don't expect it to work. I
would be overjoyed if Greg or anybody else could prove that wrong
with an optimization patch, say six to twelve months from now when
we hit that phase.
-Kevin
