From: | Clodoaldo Pinto <clodoaldo(dot)pinto(at)gmail(dot)com> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-general postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: update functions locking tables |
Date: | 2005-08-30 16:07:26 |
Message-ID: | a595de7a05083009071c3d5d54@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
30 Aug 2005 10:35:31 -0400, Greg Stark <gsstark(at)mit(dot)edu>:
>
> Well a regular vacuum will mark the free space for reuse. If you insert or
> update any records the new ones will go into those spots. Make sure you set
> the fsm_* parameters high enough to cover all the updates and inserts for the
> entire day (or repeat the vacuum periodically even if there are no deletes or
> updates going on to create more free space).
I will check those fsm_* parameters.
>
> You should realize that what's going on here is that the old records are still
> in your table, marked as deleted. So any sequential scan will take twice as
> long as otherwise. I think even index scans could take twice as long too
> depending on the distribution of values.
>
> I'm not saying that's untenable. If all your queries are fast enough then
> you're set and it's just a cost of having no downtime.
>
> --
> greg
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Cristian Prieto | 2005-08-30 16:26:59 | PostgreSQL 8.1 changes... |
Previous Message | Michael Fuhr | 2005-08-30 16:07:24 | Re: detection of VACUUM in progress |