On 2015-07-30 23:23, Tom Lane 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 ...
We could theoretically do similar thing with 64bit xmin/xmax though -
detect page is in old format and convert all tuples there to 64bit
xmin/xmax.
But I agree that we don't want to increase bloat per tuple as it's
already too big.
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).
If the page is too full we could move some data to different (or new) page.
For me bigger issue is that we'll still have to "refreeze" pages because
if tuples are updated or deleted in different epoch than the one they
were inserted in, the new version of tuple has to go to different page
and the old page will have free space that can't be used by new tuples
since the system is now in different epoch.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
