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...
Well, seems that we can remove 5 bytes from tuple header.
1. t_hoff (1 byte) may be computed - no reason to store it.
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
willoverwrite 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).
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.
>
> How is this different from the tid or oid? Reading your description, I
t_ctid could be used but would require additional disk write.
> 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 -:)
BTW, additional tid in header would allow us to implement
RI/U constraints without rules: knowing what tuples were changed
we could just read these tuples and perform checks. This would be
faster and don't require to store deffered rule plans in memory.
I'm still like the idea of deffered rules, Jan - they allow
to implement much more complex constraints than RI/U ones.
Though, did you think about [deffered] statement level triggers
implementation, Jan? You are the best one who could make it,
because of they are children of overwrite system and PL.
Vadim
