Re: reindex/vacuum locking/performance?

Поиск
Список
Период
Сортировка
От Matt Clark
Тема Re: reindex/vacuum locking/performance?
Дата
Msg-id LFEIJBEOKGPDHCEMDGNFCEPLCFAA.matt@ymogen.net
обсуждение исходный текст
Ответ на Re: reindex/vacuum locking/performance?  (Andrew Sullivan <andrew@libertyrms.info>)
Ответы Re: reindex/vacuum locking/performance?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Sullivan
Дата:
Сообщение: Re: reindex/vacuum locking/performance?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: reindex/vacuum locking/performance?