Re: reindex/vacuum locking/performance? - Mailing list pgsql-performance

From Matt Clark
Subject Re: reindex/vacuum locking/performance?
Date
Msg-id LFEIJBEOKGPDHCEMDGNFCEPLCFAA.matt@ymogen.net
Whole thread Raw
In response to Re: reindex/vacuum locking/performance?  (Andrew Sullivan <andrew@libertyrms.info>)
Responses Re: reindex/vacuum locking/performance?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
> On Sun, Oct 05, 2003 at 12:14:24PM +0100, Matt Clark wrote:
> > more info on how it clobbers shared_buffers?
>
> Vacuum is like a seqscan.  It touches everything on a table.  So it
> doesn't clobber them, but that's the latest data.  It's unlikely your
> buffers are big enough to hold your database, unless your database is
> small.  So you'll end up expiring potentially useful data in the
> buffer.

OK I'm definitely missing something here.  I thought that the FSM was there
to keep track of potentially free pages, and that all VACUUM did was double
check and then write that info out for all to see?  The promise being that a
VACUUM FULL will walk all pages on disk and do a soft-shoe-shuffle to
aggresively recover space, but a simple VACUUM won't (merely confirming
pages as available for reuse).

As for buffers, my understanding is that they are *not* meant to be big
enough to hold the DB, as PG explicitly leaves caching up to the underlying
OS.  'buffers' here meaning shared memory between PG processes, and 'cache'
meaning OS cache.  'buffers' only need to be big enough to hold the
intermediate calcs and the results for any current transactions?

M


pgsql-performance by date:

Previous
From: Andrew Sullivan
Date:
Subject: Re: reindex/vacuum locking/performance?
Next
From: Tom Lane
Date:
Subject: Re: reindex/vacuum locking/performance?