On the _need_ to vacuum...

Поиск
Список
Период
Сортировка
От Jack Bates
Тема On the _need_ to vacuum...
Дата
Msg-id 3AEA3A25.77D61E45@floatingdoghead.net
обсуждение исходный текст
Ответы Re: On the _need_ to vacuum...  (Alfred Perlstein <bright@wintelcom.net>)
Why do things slow down without a VACUUM?  (Lincoln Yeoh <lyeoh@pop.jaring.my>)
Список pgsql-general
Hello all:

I am part of a software development team evaluating RDBMSs for inclusion
as a base component of a "messaging" system.  I've been thrashing hard
on PostgreSQL under Solaris 8 and the GNU compiler for a few days now,
and personally, I'm impressed.  Thank you, developers.

The only two major problems I face when considering the use of
PostgreSQL 7.1 as released are:

1) index efficiency appears to drop over relatively short time periods
on highly volatile tables, causing producers to eventually start pulling
away from "more efficient" consumers of data in long-term tests which
include "well-oiled" situations in the load mix.

2) vacuum analyze holds an exclusive table lock for a _significant_
period of time, particularly when vacuuming tables that have been highly
volatile.

The system we are building needs to have the ability to keep chugging
along 24/7 - without _any_ long lapses of table availability.

Is there any other way to keep this type of table "preened" and
performant without a heavyweight table lock being involved?

If not, please consider this as an item for prioritized future
development.

I thank you in advance for your replies via email or this newsgroup.

--

Jack Bates
Portland, OR, USA
http://www.floatingdoghead.net
My PGP public key: http://www.floatingdoghead.net/pubkey.txt

В списке pgsql-general по дате отправления:

Предыдущее
От: Harry Yau
Дата:
Сообщение: function with multi-values
Следующее
От: The Hermit Hacker
Дата:
Сообщение: Re: are there plans for a threaded alternative to multiple daemons?