From: | Gurjeet Singh <gurjeet(at)singh(dot)im> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
Subject: | Re: 64-bit XIDs again |
Date: | 2015-07-31 06:22:42 |
Message-ID: | CABwTF4UpGrQ+AcyJ4GyfVMWqSRnyy6itA92QrdjS5k98hPu=Rg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jul 30, 2015 2:23 PM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)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?
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2015-07-31 06:29:31 | Re: Updatable view? |
Previous Message | Tatsuo Ishii | 2015-07-31 04:44:49 | Re: Updatable view? |