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