Re: [HACKERS] Savepoints...

> 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