Re: Data files became huge with no apparent reason - Mailing list pgsql-general

From Stephan Szabo
Subject Re: Data files became huge with no apparent reason
Date
Msg-id 20020828080928.Y85460-100000@megazone23.bigpanda.com
Whole thread Raw
In response to Data files became huge with no apparent reason  (Dario Fumagalli <dfumagalli@tin.it>)
List pgsql-general
On Wed, 28 Aug 2002, Dario Fumagalli wrote:

> I have a main database (proj_store) that holds 34 objects (tables and
> sequences). Only one table has more than some 100s records (the products
> table, totalling 975 records). The backend is PostgreSQL 7.1.1 on a
> Caldera Linux OpenServer, compiled from sources.
>
> A full, uncompressed SQL dump (with full inserts) is about 3,4 MB.
>
> Each day, a cron-driven program I wrote one year ago updates the
> database from a MS-SQL 7.0 server (inserts and updates only, in the
> range of 2-5 each day).

> - How is it possible this exceptional growth (N.B. the database server
> has all the default values set in its configuration files - i.e. was not
> "optimized")?

Well, updates are effectively similar to delete/insert for space usage
and the deleted space isn't freed until vacuum.  With 2-5 updates I'm
not sure why you'd get into that state, unless of course each was
say updating every row.

> - More urgently: why now it takes 30 seconds to perform a select
> count(*) on 900 records (no other clients connected), while in the past
> it was almost instantaneous? All database operations are now slow as
> dogs. And I have to live with this 52 MB until the technician comes with
> a new disk (1 week... he is in vacation now).

There are almost certainly a huge number of dead rows that it's checking
to see if you can see them.

> - Why do the backend crashed immediately if I try to VACUUM (ANALYZE)
> it? I think the backend claims additional disk space for this operation
> and fills the disk again, but I'm not sure.

Possibly making the logs, I'd guess, but I'm not sure.

> - And last, but not least... is it possible to restore the situation
> without loosing data (backup is 3 weeks old)? I'm able to start the

Either dump and restore, or once you can vacuum, vacuum.
I don't remember if 7.1.1 has vacuum verbose, but that'd give alot
of info on how many rows were erased and such.

If you decide to do a dump and restore, you might want to looking at
7.2.2 since you can do vacuums that do not block tables.


pgsql-general by date:

Previous
From: "David Blood"
Date:
Subject: Qos how to improve performace for particular connections
Next
From: Bruce Momjian
Date:
Subject: Re: psql 7.2.1 on S/390