On the _need_ to vacuum...

From: Jack Bates <postgres(at)floatingdoghead(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: On the _need_ to vacuum...
Date: 2001-04-28 03:33:57
Message-ID: 3AEA3A25.77D61E45@floatingdoghead.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

Responses

Browse pgsql-general by date

  From Date Subject
Next Message James Thornton 2001-04-28 04:00:31 Vacuum analyze keeps hanging (RedHat 6.2, PG 7.03)
Previous Message Lincoln Yeoh 2001-04-28 02:53:08 Re: SQL Where Like - Range it?!