Re: Another idea for dealing with cmin/cmax

On Mon, Oct 02, 2006 at 10:52:48AM +0900, ITAGAKI Takahiro wrote:
> 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.

Well, for data warehousing, phantom XIDs of some sort would probably be
extremely valuable. Instead of a number of 4 byte XIDs in each tuple,
place a limit on the number of transactions that can be live in a table
at once. Granted, this means the need to vacuum-freeze more often, but
since that can be done as a low-load, low-priority background process
that doesn't seem too horrible. If the same technique was applied to
cmin/cmax, you could shrink all the visibility info to 1 byte if you
wanted to.
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)