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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026