Re: Size for vacuum_mem

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
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-05 23:59:37
Message-ID: Pine.LNX.4.33.0212051657010.18114-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, 5 Dec 2002, David Blood wrote:

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

How much shared memory do you have allocated to Postgresql?

I've found that if I have a couple hundred megs of shared buffer on a
machine with 1 gig or more of ram, that lazy vacuums (in 7.2.x and later,
7.1 has massive problems with lazy vacuums acting up) don't seem to affect
performance much at all.

Vacuum on most my boxen results in no more than a 5% performance loss for
other queries (all types, select, update, delete, insert) but keeps the
database running well, even if they are running one vacuum right after
another.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message scott.marlowe 2002-12-06 00:03:23 Re: Newbee question "Types"
Previous Message scott.marlowe 2002-12-05 23:53:22 Re: the "/usr/local/pgsql/data" directory size