Re: On the _need_ to vacuum...

* Jack Bates <postgres@floatingdoghead.net> [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 - [alfred@freebsd.org]
http://www.egr.unlv.edu/~slumos/on-netbsd.html