Re: reindex/vacuum locking/performance?

From: "Matt Clark" <matt(at)ymogen(dot)net>
To: "Andrew Sullivan" <andrew(at)libertyrms(dot)info>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: reindex/vacuum locking/performance?
Date: 2003-10-05 16:46:21
Message-ID: LFEIJBEOKGPDHCEMDGNFCEPLCFAA.matt@ymogen.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2003-10-05 17:11:10 Re: reindex/vacuum locking/performance?
Previous Message Andrew Sullivan 2003-10-05 14:34:31 Re: reindex/vacuum locking/performance?