Hi,
Kevin Grittner wrote:
> I'm probably not quite as clueless as you think on this; I realize
> that keeping SIREAD locks in memory will require many more slots for
> locks, escalation from tuple level to page or coarser when there are
> many on a table, or (most likely) both.
..oh, there's the dynamic adjustment idea again. Cool!
> What I do think is that the structures for regular locks seem usable
> to track the information I need without having to burden read
> operations with disk output, which I see as absolutely necessary for
> adequate performance.
I certainly agree that SIREAD locks should never hit the disk. However,
thinking of SIREAD more as marks or hints, I'm not so sure the current
locking structures are appropriate.
If we are talking about table level locks, those are not fine grained
enough and have different semantics (i.e. a user can acquire these
locks, which certainly doesn't make any sense for SIREAD). My gut
feeling is that adjusting them for use with SIREAD is more work than
implementing your own shared memory area for SIREAD marks.
Row level locks are very fine grained, but those are spilled to disk in
its current implementation. So those are an even worse fit for the needs
of SIREAD.
> It also gives me somewhere to store locks
> related to search ranges where data doesn't currently exist, and the
> ability to store read locks from many transactions against the same
> data.
Isn't a hash table in shared memory enough to store the SIREAD locks
(and a lot simpler to manage)?
> An open question in my mind is whether I might need to keep write
> locks for serializable transactions in the shared memory lock hash
> table until commit or rollback
IIUC row level locks are kept in the tuple header until the end of the
transaction (and even beyond). Is this really a problem?
> I suppose these more persistent
> write locks should be kept out of the DEFAULT lock method, too....
I fail to understand that part. What's the DEFAULT lock method?
Regards
Markus Wanner
