Re: Shared row locking

Поиск
Список
Период
Сортировка
От Manfred Koizar
Тема Re: Shared row locking
Дата
Msg-id iqa8t0d1ih441hdtrhfet5jvlpmnh4bd7s@email.aon.at
обсуждение исходный текст
Ответ на Re: Shared row locking  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Shared row locking
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: buildfarm NetBSD/m68k tsearch regression failure
Следующее
От: Tom Lane
Дата:
Сообщение: TODO item: make world safe for spaces in build/install paths