"Anjan Dave" <adave(at)vantage(dot)com> writes:
> Question is, does the 80MB buffer allocation correspond to ~87MB per
> postmaster instance? (with about 100 instances of postmaster, that will
> be about 100 x 80MB =3D 8GB??)
Most likely, top is counting some portion of the shared memory block
against each backend process. This behavior is platform-specific,
however, and you did not tell us what platform you're on.
> Interestingly, at one point, we vacuumed the database, and the size
> reported by 'df -k' on the pgsql slice dropped very
> significantly...guess, it had been using a lot of temp files?
"At one point"? If your setup doesn't include *routine* vacuuming,
you are going to have problems with file bloat. This isn't something
you can do just when you happen to remember it --- it needs to be driven
off a cron job or some such. Or use the contrib autovacuum daemon.
You want to vacuum often enough to keep the database size more or less
regards, tom lane
In response to
pgsql-performance by date
|Next:||From: Syd||Date: 2004-01-16 02:29:24|
|Subject: IDE/SCSI disk tools to turn off write caching|
|Previous:||From: Richard Huxton||Date: 2004-01-16 00:17:42|
|Subject: Re: shared_buffer value|