On Fri, Jan 8, 2010 at 7:34 AM, Greg Stark <gsstark@mit.edu> wrote:
> On Thursday, January 7, 2010, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Thu, Jan 7, 2010 at 2:40 PM, Greg Stark <gsstark@mit.edu> wrote:
>>> On Thu, Jan 7, 2010 at 11:08 AM, Markus Wanner <markus@bluegap.ch> wrote:
>>>> Row level locks are very fine grained, but those are spilled to disk in
>>>> its current implementation. So those are an even worse fit for the needs
>>>> of SIREAD.
>>>
>>> I think we're still talking past the issue. Predicate locks are not
>>> row level, nor page level, nor table level.
>>
>> They're not? They're just floating out in space somewhere? There are
>> several possible ways to implement predicate locks, but every possible
>> method I can think of involves attaching them at one of those places.
>
> well the one place you *cannot* attach them is on the tuples. because
> you need to new able to lock hypothetical new tuples which don't exist
> yet.
Well, index tuples maybe, for next-key locking...
> yes the implementation could work by attach them to tables or indexes
> but it's representing an abstract concept which is just hanging out in
> space.
Yeah, I understand that the concept is abstract, but I'm not sure it's
bad to be talking about other kinds of locks because that's how it
will be implemented. I think a lot of this is going to end up falling
on the index AMs - we could lock have locks on GIST pages, next-key
locks on btree tuples. We'll ask each index AM if it can help with the
predicate that we're trying to lock against and if they all say no
then we lock the whole table... or that's what I'm thinking, anyway.
...Robert