On Thu, 29 May 2003, Tomas Szepe wrote:
> 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.
Is the space being taken up by stats_min, this index, some other object?
I'm not 100% sure, but after vacuums maybe
select * from pg_class order by relpages desc limit 10;
will give a good idea.
What does VACUUM FULL VERBOSE stats_min; give you?
