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

From Josh Berkus
Subject Re: getting rid of freezing
Date
Msg-id 51A4DB66.70004@agliodbs.com
Whole thread Raw
In response to Re: getting rid of freezing  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: getting rid of freezing  (Andres Freund <andres@2ndquadrant.com>)
Re: getting rid of freezing  (Robert Haas <robertmhaas@gmail.com>)
Re: getting rid of freezing  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On 05/28/2013 07:17 AM, Andres Freund wrote:
> On 2013-05-26 16:58:58 -0700, Josh Berkus wrote:
>> I was talking this over with Jeff on the plane, and we wanted to be
>> clear on your goals here:  are you looking to eliminate the *write* cost
>> of freezing, or just the *read* cost of re-reading already frozen pages?
> 
> Both. The latter is what I have seen causing more hurt, but the former
> alone is painful enough.

I guess I don't see how your proposal is reducing the write cost for
most users then?

- for users with frequently, randomly updated data, pdallvisible would
not be ever set, so they still need to be rewritten to freeze
- for users with append-only tables, allvisible would never be set since
those pages don't get vacuumed
- it would prevent us from getting rid of allvisible, which has a
documented and known write overhead

This means that your optimization would benefit only users whose pages
get updated occasionally (enough to trigger vaccuum) but not too
frequently (which would unset allvisible).  While we lack statistics,
intuition suggests that this is a minority of databases.

If we just wanted to reduce read cost, why not just take a simpler
approach and give the visibility map a "isfrozen" bit?  Then we'd know
which pages didn't need rescanning without nearly as much complexity.
That would also make it more effective to do precautionary vacuum freezing.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Planning incompatibilities for Postgres 10.0
Next
From: Andrew Dunstan
Date:
Subject: Re: Unsigned integer types