Re: Another idea for dealing with cmin/cmax

ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> 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