Re: Why is vacuum_freeze_min_age 100m?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Why is vacuum_freeze_min_age 100m?
Date: 2009-08-14 03:11:39
Message-ID: 603c8f070908132011q402e708em3653c88dc203241@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

On Thu, Aug 13, 2009 at 5:15 PM, Josh Berkus<josh(at)agliodbs(dot)com> wrote:
> Robert,
>
>> Ah.  Yeah, I agree with Tom: how would it help to make this smaller?
>> It seems like that could possibly increase I/O, if the old data is
>> changing at all, but even if it doesn't it I don't see that it saves
>> you anything to freeze it sooner.
>
> Before 8.4, it actually does on tables which are purely cumulative
> (WORM).  Within a short time, say, 10,000 transactions, the rows to be
> frozen are still in the cache.  By 100m transactions, they are in an
> archive partition which will need to be dragged from disk.  So if I know
> they won't be altered, then freezing them sooner would be better.
>
> However, I can easily manage this through the autovacuum settings.  I
> just wanted confirmation of what I was thinking.

Interesting. Thanks for the explanation.

...Robert

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul Matthews 2009-08-14 03:13:16 Custom geometry, why slow?
Previous Message Itagaki Takahiro 2009-08-14 01:53:11 Re: FDW-based dblink

Browse pgsql-performance by date

  From Date Subject
Next Message Jeremy Carroll 2009-08-14 18:00:44 Memory reporting on CentOS Linux
Previous Message Jeff Janes 2009-08-14 01:18:10 Re: Scalability in postgres