Re: Shared row locking - Mailing list pgsql-hackers

From Manfred Koizar
Subject Re: Shared row locking
Date
Msg-id iqa8t0d1ih441hdtrhfet5jvlpmnh4bd7s@email.aon.at
Whole thread Raw
In response to Re: Shared row locking  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Shared row locking
List pgsql-hackers
On Wed, 29 Dec 2004 19:57:15 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Manfred Koizar <mkoi-pg@aon.at> writes:
>> I don't see too much of a difference between #1 (an on-disk structure
>> buffered in shared memory) and #2 (a shared memory structure spilling
>> to disk).
>
>If you stand back that far, maybe you can't see a difference ;-) ...

Well, I tried to step back a bit to see the whole picture.  You think I
went too far this time?  :-)

>but the proposal on the table was for an extremely special-purpose
>on-disk structure.  I'd prefer to see first if we can solve a more
>general problem, namely the fixed size of the existing lock table.

I haven't been digging into the code for some time (:-() -- but isn't
this basically a key/value mapping with random access?  My concern is
that as soon as you start to push entries out of the memory structure
you have to implement some kind of on-disk structure to support fast
lookups, which sooner or later might lead to something that looks
suspiciously like the existing hash or btree code.

So the question is whether starting by making nbtree more flexible isn't
the lower hanging fruit...

ServusManfred


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: buildfarm NetBSD/m68k tsearch regression failure
Next
From: Tom Lane
Date:
Subject: TODO item: make world safe for spaces in build/install paths