| From: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Autovacuum loose ends |
| Date: | 2005-07-16 22:32:28 |
| Message-ID: | 42D98AFC.6050808@cheapcomplexdevices.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Tom Lane wrote:
>
> ISTM the point of the delay parameters
> for autovac is to put a lid on its impact on interactive response. Seen
> in that light, you do not care exactly which table it's hitting at the
> moment.
Unless the table in question takes a big lock when it's VACUUMed
like tables with GiST indexes do today.
Slowing down one of those vacuums on a larger table has a huge
impact on interactive responses.
With GiST indexes becoming concurrent I assume Vacuum won't lock
anymore on my tables; but I don't know if there are other index
types or condition that might make vacuums take out similar
table-wide locks.
Ron
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Brown | 2005-07-17 01:35:16 | Re: Checkpoint cost, looks like it is WAL/CRC |
| Previous Message | Tom Lane | 2005-07-16 18:06:07 | Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2005-07-17 04:13:05 | Re: Interval->day patch |
| Previous Message | Andrew Dunstan | 2005-07-16 18:33:22 | Re: fixing REL7_3_STABLE build issues |