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
