Re: Idea for getting rid of VACUUM FREEZE on cold pages

From: Jesper Krogh <jesper(at)krogh(dot)cc>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Idea for getting rid of VACUUM FREEZE on cold pages
Date: 2010-05-27 19:08:06
Message-ID: 139C8666-3F12-4380-A4E7-8B23A511D2A0@krogh.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 27/05/2010, at 20.00, Josh Berkus <josh(at)agliodbs(dot)com> wrote:

>
>> Well, maybe I'm confused here, but arranging things so that we NEVER
>> have to visit the page after initially writing it seems like it's
>> setting the bar almost impossibly high.
>
> That is the use case, though. What I've encountered so far at 3
> client
> sites is tables which are largely append-only, with a few selects and
> very few updates (< 2%) on recent data. In general, once data gets
> flushed out of memory, it goes to disk and never gets recalled, and
> certainly not written. Thinks are hunky-dory until we reach
> max_freeze_age, at which point the server has to chew through hundreds
> of gigabytes of old data just to freeze them, sometimes bringing the
> application to a halt in the process.

The data doesn't get in there in " no time" if autovacuum was aware of
inserts too it would incrementally freeze the table as it grows.

It would still cause it to be read in again but not in a big chunck.

Couldn't pages that are totally filled by the same transaction, be
frozen on the initial write?

Jesper - given my limited knowledge about how it works.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2010-05-27 19:12:08 Re: [RFC] Security label support
Previous Message Robert Haas 2010-05-27 19:02:43 Re: Why my manualy constructed raw parser tree produce failed to execute?