On the _need_ to vacuum...
От | Jack Bates |
---|---|
Тема | On the _need_ to vacuum... |
Дата | |
Msg-id | 3AEA3A25.77D61E45@floatingdoghead.net обсуждение исходный текст |
Ответы |
Re: On the _need_ to vacuum...
Why do things slow down without a VACUUM? |
Список | 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 по дате отправления: