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