Greg Stark <stark(at)enterprisedb(dot)com> wrote:
> On Thu, May 7, 2009 at 11:08 PM, Kevin Grittner
> <Kevin(dot)Grittner(at)wicourts(dot)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
Other than not blocking, I suppose.
> where you have to understand the query plan to understand why you're
> getting spurious serialization failures.
You have to know a lot more than that to solve serialization problems
in PostgreSQL with current techniques.
> 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.
Someone more familiar than I with S2PL would be better able to
respond, but I *think* you just need to track this on whatever path
is actually chosen, not on all possible paths.
> Or there could be multiple indexes on the function, we definitely
> wouldn't want to have to check for range locks on every index.
Agreed. And I don't think we have to.
> We have to think outside of the box and get away from the
> pre-existing implementations which have solutions which aren't
> really applicable.
Well, this paper is well outside the box in many respects, although it
still does use well-worn techniques for some portions of the
processing. If PostgreSQL developers can expand on that with their
own innovations, fantastic!
> 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.
That might burden this with much worse performance. I think that the
reason most products *do* base it on the actual rows, blocks, or
tables referenced is that it gives the needed behaviors with good
performance. Like I said, if we want to combine the innovations in
the paper with something clever and new in the predicate locking area,
OK -- as long as that isn't the cause for sinking the part that can
already be shown to work.
> I've removed the broken email address for now -- please re-add the
> correct email address.
I'll see what I can find. When I last corresponded with him, he was
still at the University of Sidney, working on his PhD by applying
these techniques to InnoDB. He specified that email address for
copying him when I opened the dialog. I don't think either of us
expected it to take this long for PostgreSQL to get to beta so that I
could do so. He said that when that was complete, he would be working
full-time for Oracle, so he's probably moved on to a new location and
this email address has gone stale. I'll see what I can track down.
-Kevin