Combo xids

Currently, we hold xmin and xmax for each tuple.

For xmax, we have the multixact mechanism that allows us to represent
an array of xids with just a single pseudo xid.

So why not hold xmin and xmax as part of a multixact? Instead of
caching two xids on each tuple, why not hold just one and allow access
to the array of xids via multixact?

An idea very similar to combo cids, hence the name combo xids.

When would this make sense?
Frequently. Most of the time a tuple needs only one xid set. In most
cases, we set xmin and xmax a long time apart. Very few cases end with
both of them set inside the *same* xmin horizon. In a heavy
transactional enviroment, the horizon moves forwards quickly, on the
order of a few seconds. Very few rows get inserted and then
updated/deleted that quickly. With long reporting queries, data tends
to be updated less, so again the rows aren't touched within the same
horizon. As a result, we hardly ever need both xmin and xmax at the
same time - when we need to set xmax, xmin is already
committed/cleaned.

What is the benefit?
Merging xmin/xmax would save 4 bytes per row. On servers with 8 byte
word length, that means that we'd save 8 bytes per row for tables that
have between 9 and 40 columns. Which is the majority of tables.

How?
Clearly this would require changes to tuple format and therefore not
something I would suggest for this year ahead, but seems worth getting
the idea down, even if it gets ruled out.

Multixact is now persistent, so this change wouldn't take much to implement.

Given that it would require a change in in-disk format, we might also
consider that it could be possible to cache multixactid data on the
disk blocks that need it. A list of multixactids could be stored in
amongst the tuples on block, with the head of the list being a 2 byte
addition to the block header. Which could be used to reduce the
overhead of multixactid use.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services