Re: User-facing aspects of serializable transactions - Mailing list pgsql-hackers

From Greg Stark
Subject Re: User-facing aspects of serializable transactions
Date
Msg-id 9DD3ABFD-1C5F-4AE2-B43F-D30026C81DF3@enterprisedb.com
Whole thread Raw
In response to Re: User-facing aspects of serializable transactions  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: User-facing aspects of serializable transactions  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: User-facing aspects of serializable transactions  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers

On 28 May 2009, at 01:51, "Kevin Grittner"  
<Kevin.Grittner@wicourts.gov> wrote:

> At the point where we added an escalation
> to table locking for the limit, started with the table lock when we
> knew it was a table scan, and locked the index range for an index
> scan,

I still think you're stuck in the mssql/sybase mode of thought here.  
Postgres supports a whole lot more scan types than just these two and  
many of them use multiple indexes or indexes that don't correspond to  
ranges of key values at all.

I think you have to forget about any connection between predicates and  
either indexes or scan types. You need a way to represent predicates  
which can be stored and looked up independently of any indexes.

Without any real way to represent predicates this is all pie in the  
sky. The reason we don't have predicate locking is because of this  
problem which it sounds like we're no closer to solving.




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: User-facing aspects of serializable transactions
Next
From: Robert Haas
Date:
Subject: Re: PostgreSQL Developer meeting minutes up