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
On Sat, Jun 01, 2013 at 09:22:05AM +0100, Simon Riggs wrote:
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
On 01.06.2013 11:22, Simon Riggs wrote:
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.
Hmm, it would probably be
On 1 June 2013 19:25, Heikki Linnakangas hlinnakan...@vmware.com wrote:
Hmm, it would probably be much easier to squeeze, say, one byte from the
tuple header, than full four bytes. Then you could store store a null bitmap
for upto 16 columns, without crossing the 24 byte mark. That would