I suppose there must be reasons not to do this, but have you considered using the "slack" space (empty space) in an ordinary table "heap" page to store share-locks on the tuples in that page? (If not enough space is available then you would still need to use the spilled-to-disk btree structure.)
No, I hadn't considered it. However this seems hard to do, because the
"slack space" does not have a start point; on each page, elements
(tuples) grow from the back to the front, while element pointers grow
in the reverse direction. So I don't see how would this be done.
Would it work for an updater, who finds that the locks list (currently located in the middle of the empty space) is "in the way" of a new tuple that he wants to insert, to take some kind of lock, move the whole list up or down (spilling some of these locks to the disk if no more space is available), and release it again?
Could the lock(s) on a particular tuple be tacked onto the end of that tuple? (I think tuples are stored variable-width anyway, aren't they?) I suppose this is conceptually equivalent to adding a variable width system column which gets TOASTED when it gets too wide. I suppose this would make taking a lock as expensive as doing an update, though, right?
Paul Tillotson
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
