Nikhil,
Vacuuming the DB removes deleted entries from the database as they are not
actually deleted when you use SQL to delete them, just marked as deleted.
This operation clears up space and rearranges the data. If you don't
perform many deletes, you may not need to run this. The only wrinkle is
that you have to use the ANALYZE command to allow the database to generate
statistics used in query planning. You should run this perdiodically after
a large number of inserts or deletes has taken place. This command must be
used in conjunction with VACUUM which slows down the database. There was
talk of allowing the ANALYZE command to run independently of the VACUUM
command, but I'm not sure when this will happen. I'm not completely clear
on WAL functionality, but I believe that it automatically reuses the space
taken up by deleted rows in the database. Someone on the list can probably
correct me if any of this is incorrect.
---------------------------------------------
Nathan Barnett
-----Original Message-----
From: Nikhil G. Daddikar [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 13, 2000 3:21 AM
To: Nathan Barnett; [EMAIL PROTECTED]
Subject: Re: [GENERAL] Reliability Stability of PgSQL & it's JDBC driver
Nathan,
Thanks for your response. It is great to know that Postgres is working out
fine. However, I don't understand what "Vaccum of the DB" means nor what
the "WAL" functionality is. If you could briefly explain these, that would
be great.
Thanks again!
-ngd.
> The main problem that you have in a production system is the VACUUM of the
database.
> This will in most cases severely inhibit performance. If your system
isn't
> 24x7, then you should be fine as you can schedule this for off times. I
> believe that the need to vacuum the database will be removed in the next
> version due to WAL functionality, but I'm sure someone else is better
> qualified to explain that. I just wanted to vouch for the stability of
> Postgres in a production environment.
