<p dir="ltr"><br /> On Jul 30, 2015 2:23 PM, "Tom Lane" <<a
href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>>wrote:<br /> ><br /> > Gavin Flower <<a
href="mailto:GavinFlower@archidevsys.co.nz">GavinFlower@archidevsys.co.nz</a>>writes:<br /> > > On 31/07/15
02:24,Heikki Linnakangas wrote:<br /> > >> There is a big downside to expanding xmin/xmax to 64 bits: it
takes<br/> > >> space. More space means more memory needed for caching, more memory<br /> > >>
bandwidth,more I/O, etc.<br /> ><br /> > > I think having a special case to save 32 bits per tuple would
cause<br/> > > unnecessary complications, and the savings are minimal compared to the<br /> > > size of
currentmodern storage devices and the typical memory used in<br /> > > serious database servers.<br /> ><br />
>I think the argument that the savings are minimal is pretty thin.<br /> > It all depends on how wide your tables
are--- but on a narrow table, say<br /> > half a dozen ints, the current tuple size is 24 bytes header plus the
same<br/> > number of bytes of data. We'd be going up to 32 bytes header which makes<br /> > for a 16% increase
inphysical table size. If your table is large,<br /> > claiming that 16% doesn't hurt is just silly.<br /> ><br
/>> But the elephant in the room is on-disk compatibility. There is<br /> > absolutely no way that we can just
changexmin/xmax to 64 bits without a<br /> > disk format break. However, if we do something like what Heikki is<br
/>> suggesting, it's at least conceivable that we could convert incrementally<br /> > (ie, if you find a page
withthe old header format, assume all tuples in<br /> > it are part of epoch 0; and do not insert new tuples into it
unlessthere<br /> > is room to convert the header to new format ... but I'm not sure what we<br /> > do about
tupledeletion if the old page is totally full and we need to<br /> > write an xmax that's past 4G).<p dir="ltr">Can
wesafely relegate the responsibility of tracking the per block epoch to a relation fork?