Skip site navigation (1) Skip section navigation (2)

Re: User-facing aspects of serializable transactions

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Greg Stark" <stark(at)enterprisedb(dot)com>
Cc: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Jeff Davis" <pgsql(at)j-davis(dot)com>, "<pgsql-hackers(at)postgresql(dot)org>" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: User-facing aspects of serializable transactions
Date: 2009-05-28 16:29:30
Message-ID: 4A1E759A.EE98.0025.1@wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
Greg Stark <stark(at)enterprisedb(dot)com> wrote:
> On Thu, May 28, 2009 at 4:33 PM, Kevin Grittner wrote:
>>
>> Can you cite anywhere that such techniques have been successfully
>> used in a production environment
> 
> Well there's a reason our docs say: "Such a locking system is
> complex to implement and extremely expensive in execution"
 
I'm not clear on the reason for insisting that we use techniques that
*nobody* expects will work well.
 
>> or are you suggesting that we break new
>> ground here?  (The techniques I've been assuming are pretty
>> well-worn and widely used.)
> 
> Well they're well-worn in very different databases which have much
> less flexibility in how they access data. In part that inflexibility
> comes *from* their decision to implement transaction isolation using
> locks and to tie those locks to the indexing infrastructure.
 
I really don't see that.  The btree usage seems pretty clear.  The
other indexes seem solvable, with some work.  And there's an
incremental path this way, where we can get basic functionality
correct and tune one thing at a time until performance is acceptable. 
At the high end, we could even break this new ground and see if it
works better, although I personally doubt it will.
 
-Kevin

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-05-28 16:29:40
Subject: Re: PostgreSQL Developer meeting minutes up
Previous:From: Greg SmithDate: 2009-05-28 16:28:15
Subject: Re: PostgreSQL Developer meeting minutes up

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group