Re: Serializable Isolation without blocking
От | Greg Stark |
---|---|
Тема | Re: Serializable Isolation without blocking |
Дата | |
Msg-id | 407d949e1001080434xefb0e3cha000ef2f5afa0743@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Serializable Isolation without blocking (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Serializable Isolation without blocking
Re: Serializable Isolation without blocking Re: Serializable Isolation without blocking |
Список | pgsql-hackers |
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. 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. > >> 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 > -- greg
В списке pgsql-hackers по дате отправления: