Re: Shared row locking

Alvaro Herrera wrote:
> The btree idea:
> - does not need crash recovery. Maybe we could use a stripped down
> version of nbtree. This could cause a maintanibility nightmare.

Are you saying the btree is an index with no heap? If so, what about
the xid's? Are they just in the btree?

How does the btree get cleaned up over time?

> The bitmap idea:
> - seems to have lower overhead
>
> - can use the same lazy cleanup mechanism exposed for the btree idea (in
> which case we don't need the list in local memory).

You mean all empty/zero rows can be removed? Can we guarantee that on
commit we can clean up the bitmap? If not the idea doesn't work.

> - What can happen in presence of large max_connections settings? Is
> this a real problem?

I thought about that. 50 backends is 7 bytes, 1000 backends is 128
bytes. For a large number of backends you could just allow X concurrent
locks and use space X*4 bytes.

I think the basic issue is that the btree can be of variable length
while the bitmap has to be of a fixed length.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073