[GENERAL] On the _need_ to vacuum...
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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] On the _need_ to vacuum...
* Jack Bates [EMAIL PROTECTED] [010428 13:31] wrote: 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. There's a fix for Postgresql 7.0.3 here: http://www.freebsd.org/~alfred/vacfix I'm strongly considering taking the patches offline and reselling them as I seem to be the only source for them nowadays. -- -Alfred Perlstein - [[EMAIL PROTECTED]] http://www.egr.unlv.edu/~slumos/on-netbsd.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
