Re: Freeze avoidance of very large table. - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Freeze avoidance of very large table.
Date
Msg-id 55A055F4.2040908@BlueTreble.com
Whole thread Raw
In response to Re: Freeze avoidance of very large table.  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On 7/10/15 4:46 AM, Simon Riggs wrote:
> On 10 July 2015 at 09:49, Sawada Masahiko <sawada.mshk@gmail.com
> <mailto:sawada.mshk@gmail.com>> wrote:
>
>
>     > It is a minor thing, but if there is no other use for this fourth
>     > "bit-space", it seems a shame to waste it when there is some use for it.  I
>     > haven't looked at the code around this area to know how hard it would be to
>     > implement the setting and clearing of the bit.
>
>     I think so too, we would be able to use unused fourth status of bits
>     efficiently.
>     Should I include these improvement into this patch?
>     This topic should be discussed on another thread after this feature is
>     committed, I think.
>
>
> The impossible state acts as a diagnostic check for us to ensure the
> bitmap is not itself corrupt.
>
> -1 for using it for another purpose.

AFAICS empty page is only interesting for vacuum truncate, which is a 
very short-term thing. It would be better to find a way to handle that 
differently.

In any case, that should definitely be a separate discussion from this 
patch.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg_upgrade + Extensions
Next
From: Noah Misch
Date:
Subject: Re: more RLS oversights