From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Dario Fumagalli <dfumagalli(at)tin(dot)it> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Data files became huge with no apparent reason |
Date: | 2002-08-28 15:15:41 |
Message-ID: | 20020828080928.Y85460-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-08-28 15:17:28 | Re: psql 7.2.1 on S/390 |
Previous Message | David Blood | 2002-08-28 15:12:34 | Qos how to improve performace for particular connections |