From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Markus Wanner <markus(at)bluegap(dot)ch>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, nicolas(dot)barbier(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, laurenz(dot)albe(at)wien(dot)gv(dot)at |
Subject: | Re: Serializable Isolation without blocking |
Date: | 2010-01-07 20:02:33 |
Message-ID: | 603c8f071001071202m103c12bex8fe203f5e3808ffd@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 7, 2010 at 2:40 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> On Thu, Jan 7, 2010 at 11:08 AM, Markus Wanner <markus(at)bluegap(dot)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.
> And how do you do that without tying the implementation to specific
> details of how our planner, table scans, and index access methods
> work?
You don't. You add additional methods to the index AMs to support
predicate locks, just lilke we do when we want them to support
anything else (bitmap index scans, index-only scans, etc.).
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2010-01-07 20:03:18 | Re: Hot Standy introduced problem with query cancel behavior |
Previous Message | Heikki Linnakangas | 2010-01-07 19:58:10 | Re: PostgreSQL 8.5 Open Items |