On the _need_ to vacuum...
Jack Bates <postgres@floatingdoghead.net>
From: Jack Bates <postgres@floatingdoghead.net>
To: pgsql-general@postgresql.org
Date: 2001-04-28T03:33:57Z
Lists: 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