> Bruce Momjian wrote:
> >
> > > To have them I need to add tuple id (6 bytes) to heap tuple
> > > header. Are there objections? Though it's not good to increase
> > > tuple header size, subj is, imho, very nice feature...
> >
> > Gee, that's a lot of overhead. We would go from 40 bytes ->46 bytes.
>
> 40? offsetof(HeapTupleHeaderData, t_bits) is 31...
Yes, I saw this. I even updated the FAQ to show a 32-byte overhead.
> Well, seems that we can remove 5 bytes from tuple header.
I was hoping you could do something like this.
> 1. t_hoff (1 byte) may be computed - no reason to store it.
Yes.
> 2. we need in both t_cmin and t_cmax only when tuple is updated
> by the same xaction as it was inserted - in such cases we
> can put delete command id (t_cmax) to t_xmax and set
> flag HEAP_XMAX_THE_SAME (as t_xmin), in all other cases
> we will overwrite insert command id with delete command id
> (no one is interested in t_cmin of committed insert xaction)
> -> yet another 4 bytes (sizeof command id).
Good.
>
> If now we'll add 6 bytes to header then
> offsetof(HeapTupleHeaderData, t_bits) will be 32 and for
> no-nulls tuples there will be no difference at all
> (with/without additional 6 bytes), due to double alignment
> of header. So, the choice is: new feature or more compact
> (than current) header for tuples with nulls.
That's a tough one. What do other DB's have for row overhead?
> > How is this different from the tid or oid? Reading your description, I
>
> t_ctid could be used but would require additional disk write.
OK, I understand.
>
> > see there probably isn't another way to do it.
>
> There is one - WAL. I'm thinking about it, but it's too long story -:)
OK.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026