Re: Serializable Isolation without blocking

From: Greg Stark <stark(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, "Michael Cahill mjc"(at)it(dot)usyd(dot)edu(dot)au, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Serializable Isolation without blocking
Date: 2009-05-07 21:32:12
Message-ID: 4136ffa0905071432p67ce9343h3d1e78702233cb36@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 7, 2009 at 6:31 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> Each user must compare against work performed by all other users. O(N).
>
> There are N users, so O(N^2).

i think this logic only works if you must scan every item for every
other user every time. If you have data structures like binary trees
or whatever to fine any matching predicate locks or intent locks or
whatever we're calling them then you can hopefully find them in faster
than O(N) time.

I'm not sure you can do better than a full linear search though. If I
do something like "SELECT count(*) FROM tab WHERE
complex_function(a,b) = 5"

And then you "INSERT INTO tab (a,b) VALUES (1,2)". How would you store
any record of the fact that there's a serialization failure iff
complex_function(1,2)=5 in any way that lets you look it up in any way
other than evaluating complex_function for every set of values
inserted?

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2009-05-07 21:37:56 Re: Serializable Isolation without blocking
Previous Message Tom Lane 2009-05-07 21:19:32 Re: Some 8.4 changes needed according to pg_migrator testing