| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Tianzhou Chen <tianzhouchen(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Challenges preventing us moving to 64 bit transaction id (XID)? |
| Date: | 2017-06-07 10:49:00 |
| Message-ID: | 20170607104900.codltdttnt6nri2f@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alexander Korotkov wrote:
> Right. I used the term "64-bit epoch" during developer unconference, but
> that was ambiguous. It would be more correct to call it a "64-bit base".
> BTW, we will have to store two 64-bit bases: for xids and for multixacts,
> because they are completely independent counters.
So this takes us from 4 additional bytes per page, to 16 additional
bytes per page. With the proposal to require 4 free bytes it seemed
quite unlikely that many pages would fail to comply (so whatever
fallback mechanism was needed during page upgrade would be seldom used),
but now that they are 16, the likelihood of needing to run that page
upgrade seems a tad high.
Instead of adding a second 64 bit counter for multixacts, how about
first implementing something like TED which gets rid of multixacts (and
freezing thereof) altogether?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Khandekar | 2017-06-07 11:12:25 | Re: UPDATE of partition key |
| Previous Message | Alexander Korotkov | 2017-06-07 10:42:04 | Re: Challenges preventing us moving to 64 bit transaction id (XID)? |