Re: 64-bit XIDs again

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 64-bit XIDs again
Date: 2015-08-01 07:42:03
Message-ID: CANP8+jJkwMvbgS=NTwvf0Riq-YF2sYu0P8vmjH2rjVnEUQLs1A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 31 July 2015 at 22:46, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:

> On 07/31/2015 12:29 AM, Josh Berkus wrote:
>
>> On 07/30/2015 07:24 AM, Heikki Linnakangas wrote:
>>
>>>
>>> You'd never be forced to do anti-wraparound
>>> vacuums, you could just let the clog grow arbitrarily large
>>>
>>
>> When I introduced the same idea a few years back, having the clog get
>> arbitrarily large was cited as a major issue. I was under the
>> impression that clog size had some major performance impacts.
>>
>
> Well, sure, if you don't want the clog to grow arbitrarily large, then you
> need to freeze.

This statement isn't quite right, things are better than that.

We don't need to freeze in order to shrink the clog, we just need to hint
and thereby ensure we move forwards the lowest unhinted xid. That does
involve scanning, but doesn't need to scan indexes. That scan won't produce
anywhere near as much additional WAL traffic or I/O.

In practice, larger clog would only happen with higher transaction rate,
which means more system resources, so I don't think its too much of a
problem overall.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Shay Rojansky 2015-08-01 09:47:31 Re: Encoding of early PG messages
Previous Message Noah Misch 2015-08-01 06:56:26 Re: security labels on databases are bad for dump & restore