Hello everybody, I'm facing a simple yet gravely problem with postgresql 7.3.2 on x86 Linux. My db is used to store IP accounting statistics for about 30 C's. There are a couple truly trivial tables such as the one below:
CREATE TABLE stats_min ( ip inet NOT NULL, start timestamp NOT NULL default CURRENT_TIMESTAMP(0), intlen int4 NOT NULL default 60, d_in int8 NOT NULL, d_out int8 NOT NULL, constraint "stats_min_pkey" PRIMARY KEY ("ip", "start") ); CREATE INDEX stats_min_start ON stats_min (start); A typical transaction committed on these tables looks like this: BEGIN WORK DELETE ... UPDATE/INSERT ... COMMIT WORK Trouble is, as the rows in the tables get deleted/inserted/updated (the frequency being a couple thousand rows per minute), the database is growing out of proportion in size. After about a week, I have to redump the db by hand so as to get query times back to sensible figures. A transaction that takes ~50 seconds before the redump will then complete in under 5 seconds (the corresponding data/base/ dir having shrunk from ~2 GB to ~0.6GB). A nightly VACCUM ANALYZE is no use. A VACUUM FULL is no use. A VACUUM FULL followed by REINDEX is no use. It seems that only a full redump involving "pg_dump olddb | \ psql newdb" is capable of restoring the system to its working glory. Please accept my apologies if I've overlooked a relevant piece of information in the docs. I'm in an urgent need of getting this problem resolved. -- Tomas Szepe <[EMAIL PROTECTED]> ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster