2010/1/7 Albe Laurenz <laurenz.a...@wien.gv.at>:

> Nicolas Barbier wrote:
>
>> In such a pure implementation of predicate locking, the overlap
>> testing is be done using the algebraic properties of the conditions,
>> which is of course extremely difficult (if not impossible) to
>> implement perfectly in a system that allows conditions of arbitrary
>> complexity. Therefore, the conditions are typically simplified in such
>> a way that they become true for more rows, but are easier to check for
>> overlap.
>
> That sounds like major AI to me.

It is, but only if you want to approach perfection, which is probably
not the way to go.

> What do you do if the condition involves user defined functions?

Then you have to become conservative, I guess: if you don't know
otherwise, you assume it *might* do the bad thing: the predicate might
match any inputs (i.e., you could convert such a condition to a
whole-table lock if there are no other restrictions ANDed to it).

> Are there any implementations taking such an approach?

I personally don't know of any production-ready DBMSs that use any
predicate locking approach other than the "access layer based" one
(i.e., locking index ranges and falling back to whole-table locks for
table scans); but then, I am not an expert in this matter.

I think that it is a good thing in itself to remove plan dependencies
(which would be accomplished by locking on the algebraic level), but
it seems that none other the other DBMSs were able to implement it
like that.

Nicolas

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to