From: | Vivek Khera <vivek(at)khera(dot)org> |
---|---|
To: | pgsql-performance Performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Replication Syatem |
Date: | 2008-04-29 15:00:57 |
Message-ID: | 5C077297-F9AA-4890-87BF-DFBC677DEDFF@khera.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Apr 29, 2008, at 10:16 AM, Tom Lane wrote:
> Greg Smith <gsmith(at)gregsmith(dot)com> writes:
>> The model here assumes that you'll need that space again for the
>> next time
>> you UPDATE or INSERT a row. So instead VACUUM just keeps those
>> available
>> for database reuse rather than returning it to the operating system.
[ ... ]
> Also, you need to make sure you have the FSM parameters set high
> enough
> so that all the free space found by a VACUUM run can be remembered.
>
> The less often you run VACUUM, the more FSM space you need, because
> there'll be more free space reclaimed per run.
I can actually watch one of our applications slow down once the free
space in the table is used up. Extending the data file seems to be
much more expensive than using the free space found in existing pages
of the file.
From | Date | Subject | |
---|---|---|---|
Next Message | John Rouillard | 2008-04-29 15:04:32 | Re: Very poor performance loading 100M of sql data using copy |
Previous Message | Chris Browne | 2008-04-29 14:48:28 | Re: Replication Syatem |