Re: Another idea for dealing with cmin/cmax

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Jim C. Nasby" <jim(at)nasby(dot)net> writes:
> > Dumb question... wouldn't getting down to 20 bytes buy us something?
>
> BTW, the apparently useless byte after the 27- or 23-byte header
> actually has some good use: in a table of up to 8 columns, you can
> fit a null bitmap there "for free". In a scheme that took us down
> to 20 rather than 19 bytes, even a narrow table would pay the full
> maxalign price for having a null.

We may use "free" bytes for other purposes. For example, if we increase
the size of XIDs from 4 to 6 bytes, we can get rid of transaction
wraparound problem. There may be some other uses.

> I'm in favor of combining cmin/cmax/xvac to get us down to 23 bytes,
> but I think anything beyond that is going to face a serious problem
> of greatly increased cost for diminishing returns.

If we really want to reduce the size of headers to 16 bytes,
we maybe need to do with HeapTupleHeaderData.t_ctid .

Under the assumption that tuples are offen updated in the same page,
we only need offsets in the page to link an old tuple to new one.
We can reduce the size of t_ctid from 6 to 2 bytes. When tuples
are updated to other pages, we probably need "phantom ctid".

In another assumption that tuples are offen updated after frozen,
we can overlap ctid and xmin to a physical field using union.
But "phantom xids" are needed to update unfrozen tuples.

However, I think both assumptions have less probability than
the one assumed when we introduce phantom cids.
The above ideas probably do not work well.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center