On Thu, May 7, 2009 at 11:08 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> I would assume that SELECT shown above would either resolve to a
> table scan, in which case you would have to have an SIREAD lock at the
> table level
That sounds like we're back to the MSSQL/Sybase way of doing things
where you have to understand the query plan to understand why you're
getting spurious serialization failures. I don't think that's terribly
appealing. Consider, for example, that we might not *want* to do an
index scan just because there's an index. Or there could be multiple
indexes on the function, we definitely wouldn't want to have to check
for range locks on every index.
We have to think outside of the box and get away from the pre-existing
implementations which have solutions which aren't really applicable.
If we were to look at doing predicate locks in any way they would
probably be stored in a whole new data structure, not related to the
indexes on the table. We would need some way to index them so that we
can look for conflicting locks efficiently independently from the
query plan and table access methods.
I've removed the broken email address for now -- please re-add the
correct email address.
--
greg
