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