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.
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? |