Message-ID: <54D029E0.7000800@BlueTreble.com>
Date: Mon, 2 Feb 2015 19:52:32 -0600
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Slava Mudry <slava44@gmail.com>, "pgsql-performance@postgresql.org"
 <pgsql-performance@postgresql.org>
Subject: Re: why pg_class.relfrozenxid needs to be updated for frozen
 tables (where all rows have xmin=2)?
References: 
 <CAEFxPe3pd5B1ssKvAkUuKULRd+YdYpXTpteZzPtQ88xvrJT5OQ@mail.gmail.com>
	<54CC2FBA.1040506@BlueTreble.com>
 <CAEFxPe3UbWnZdWZO-AA+PyhLvrLsEwL7bJUEsGoDTYW-xBmLjA@mail.gmail.com>
 <54D0260F.40508@BlueTreble.com>
In-Reply-To: <54D0260F.40508@BlueTreble.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2015 01:52:40.0953 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR11MB0342
X-Pg-Spam-Score: -1.9 (-)
List-Archive: <http://archives.postgresql.org/pgsql-performance>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-performance.postgresql.org>
List-Owner: <mailto:pgsql-performance-owner@postgresql.org>
List-Post: <mailto:pgsql-performance@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-performance>
List-Unsubscribe: 
 <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
X-Mailing-List: pgsql-performance
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 2/2/15 7:36 PM, Jim Nasby wrote:
>>
>> Currently the fact that it needs to go back to old tables and FTS them
>> every 2B transactions (or rely on autovacuum for this) and you can't do
>> anything about it (like permanently freeze the tables) seems like a big
>> scalability issue. Does it not?
>
> Unfortunately it's not terribly easy to fix this. The problem is if we
> try to play games here, we must have a 100% reliable method for changing
> relfrozenxid as soon as someone inserts a new tuple in the relation. It
> might be possible to tie this into the visibility map, but no one has
> looked at this yet.
>
> Perhaps you'd be willing to investigate this, or sponsor the work?

Oh, there is another possibility that's been discussed: read-only 
tables. If we had the ability to mark a table read-only, then a VACUUM 
FREEZE on such a table would be able to set that table's relfrozenxid to 
FrozenTransactionId and prevent any further attempts at vacuuming. This 
might be easier than trying to do something automatic.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance