Re: getting rid of freezing - Mailing list pgsql-hackers

From Robert Haas
Subject Re: getting rid of freezing
Date
Msg-id CA+Tgmobn4qjsT5esEOhSaUSxyk3wMBFtM60SbARbEEMw-Ud9LA@mail.gmail.com
Whole thread Raw
In response to Re: getting rid of freezing  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: getting rid of freezing  (Andres Freund <andres@2ndquadrant.com>)
Re: getting rid of freezing  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, May 24, 2013 at 10:53 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> [all-visible cannot restore hint bits without FPI because of torn pages]
>
> I haven't yet thought about this sufficiently yet. I think we might have
> a chance of working around this, let me ponder a bit.

Yeah.  I too feel like there might be a solution.  But I don't know
have something specific in mind, yet anyway.

> But even if that means needing a full page write via the usual mechanism
> for all visible if any hint bits needed to be set we are still out far
> ahead of the current state imo.
> * cleanup would quite possibly do an FPI shortly after in vacuum
>   anyway. If we do it for all visible, it possibly does not need to be
>   done for it.
> * freezing would FPI almost guaranteedly since we do it so much
>   later.
> * Not having to rescan the whole heap will be a bigger cost saving...

The basic problem is that if the data is going to be removed before it
would have gotten frozen, then the extra FPIs are just overhead.  In
effect, we're just deciding to freeze a lot sooner.  And while that
might well be beneficial in some use cases (e.g. the data's already in
cache) it might also not be so beneficial (the table is larger than
cache and would have been dropped before freezing kicked in).

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: German Becker
Date:
Subject: Re: WAL segments (names) not in a sequence
Next
From: Amit Langote
Date:
Subject: Re: WAL segments (names) not in a sequence