From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David Blood" <david(at)matraex(dot)com> |
Cc: | "'Robert Treat'" <xzilla(at)users(dot)sourceforge(dot)net>, "'Francisco Reyes'" <lists(at)natserv(dot)com>, neilc(at)samurai(dot)com, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Size for vacuum_mem |
Date: | 2002-12-06 19:56:47 |
Message-ID: | 12426.1039204607@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"David Blood" <david(at)matraex(dot)com> writes:
> A "lazy vacuum" can hurt If you have lots of i/o. If we try to run it
> during the day it kills us. This is because to vacuum all the tables
> postgres has to read them from the disk. While it doesn't not lock rows
> it does block other rows from reading/writing to/from the disk.
On the other hand, I have watched people lazy-vacuum production
databases in 7.2.* and not seen any visible hit on system load
(as far as top or vmstat could show, anyway).
I think it may be a matter of whether you have disk bandwidth to
spare. If the disk farm is marginal, the extra demand from a vacuum
may push you over the knee of the performance curve. But that's just
a guess. It would be interesting if some folks from the "it doesn't
hurt" and the "it does hurt" camps could compare notes and try to
understand the reason for the difference in their results.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Fernando Papa | 2002-12-06 20:20:03 | Table functions say "no destination for result data." |
Previous Message | Bruce Momjian | 2002-12-06 19:07:13 | Re: [7.3] can't connect with SSL |