ITAGAKI Takahiro <[EMAIL PROTECTED]> writes: > ITL-like approach is more efficient than per-tuple XIDs > unless all tuples in a page are locked at the same time. > However, MAXTRANS and PCTFREE issues may bother us.
I'm not sure how Oracle gets away with MAXTRANS. Somehow it seems to never arise as a practical problem yet it seems like there must be instances where it would cause a serious problems. It's worse for Postgres since as I understand it Oracle only needs to track transaction ids that are actively locking the record. Postgres needs to track transaction ids for the inserting and deleting transaction even when there's no lock (or no lock remaining). I can imagine having a scheme where there's a short list of transaction ids in the footer and then each tuple just stores an index into that list. If you had space for 16 transaction ids set aside then you could store xmin and xmax in a single byte for example. If the space set aside for these transaction ids is full when you're inserting i suppose you could just go back to the FSM for another page. But I don't see any way out when you're deleting. You have to mark xmax one way or another and if there's no space left in the footer and you only have 4 bits in the tuple what are you going to do? As an aside doing vacuum freeze more aggressively might reduce the pressure on these ITL slots. But I don't see any way to guarantee a slot is available for xmax when deleting. We would need some sort of scheme where the space for transaction ids is able to grow but we're already growing from both ends of the page. We would either have to interleave transaction ids with line pointers or store them on another special page somewhere. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
