Greg Stark <stark@enterprisedb.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