Per tuple overhead, cmin, cmax

Hi,

having been chased away from pgsql-novice by Rasmus Mohr, I come here
to try my luck :-) I'm still new to this; so please be patient, if I
ask silly questions.

There has been a discussion recently about saving some bytes per tuple
header. Well, I have the suspicion, we can eliminate 4 bytes more by
using one single field for t_cmin and t_cmax. Here are my thoughts
supporting this feeling:

(1) The purpose of the command ids is to prevent a command from
working on the same tuple more than once. 2002-04-20 Tom Lane wrote
in "On-disk Tuple Size":
> You don't want an individual command's effects to become visible
> until you do CommandCounterIncrement.
and
> The command IDs aren't interesting anymore once the originating
> transaction is over, but I don't see a realistic way to recycle the
> space ...

(2) The command ids are of any meaning (2a) only during the active
transaction (with the exception of the (ab)use of t_cmin by vacuum);
and (2b) we are only interested in whether t_cxxx is less than the
current command id, if it is, we don't care about the exact value.

(3) From a command's view a tuple can be in one of these states:

(3a) Neither t_xmin nor t_xmax is the current transaction. The tuple
has been neither inserted nor deleted (and thus not updated) by this
transaction, and the command ids are irrelevant.

(3b) t_xmin is the current transaction, t_xmax is
InvalidTransactionId; i.e. the tuple has been inserted by the current
transaction and it has not been deleted (or replaced). In this case
t_cmin identifies the command having inserted the tuple, and t_cmax is
irrelevant.

(3c) t_xmin is some other transaction, t_xmax is the current
transaction; i.e. the current transaction has deleted the tuple.
Then t_cmax identifies the command having deleted the tuple, t_cmin is
irrelevant.

(3d) t_xmin == t_xmax == current transaction. The tuple has been
inserted and then deleted by the current transaction. Then I claim
(but I'm not absolutely sure), that insert and delete cannot have
happened in the same command,
so t_cmin < t_cmax,
so t_cmin < CurrentCommandId,
so the exact value of t_cmin is irrelevant.

So at any moment at most one of the two fields t_cmin and t_cmax is
needed.

(4) If (3) is true, we can have a single field t_cnum in
HeapTupleHeaderData, the meaning of which is t_cmax, if t_xmax is the
current transaction, otherwise t_cmin.

t_cmin is used in:
. backend/access/common/heaptuple.c
. backend/access/heap/heapam.c
. backend/access/transam/xlogutils.c
. backend/commands/vacuum.c
. backend/utils/time/tqual.c

t_cmax is used in:
. backend/access/common/heaptuple.c
. backend/access/heap/heapam.c
. backend/utils/time/tqual.c

As far as I have checked these sources (including the abuse of c_tmin
by vacuum) my suggested change should be possible, but as I told you
I'm new here and so I have the following questions:

(Q1) Is assumption (3d) true? Do you have any counter examples?

(Q2) Is there any possibiltity of t_cmax being set and t_cmin still
being needed? (Preferred answer: no :-)

(Q3) Are my thoughts WAL compatible?

(Q4) Is it really easy to change the size of HeapTupleHeaderData? Are
the data of this struct only accessed by field names or are there
dirty tricks using memcpy() and pointer arithmetic?

(Q5) Are these thoughts obsolete as soon as nested transactions are
considered?

Thank you for reading this long message.

Servus
Manfred