- Q. Bad knews that VACUUM must eventually scan every row(in fact, every rowOn heavily used databases (over 100,000 transactions an hour), vacuum is a killer and
and index pages?) in the database(?): - if this is true(?) then can anyone give an idea on how long it runs
for a paticular size of the database and how much it slowdowns a database?
needs to be run pretty much concurrently with operation. This is especially true if you
database is doing large amounts of updates and deletes. Vacuum is also very hard on
the database hardware, if you do not want to see significant performance hits -- you
need to have a lot of hard drive IO. Think 4-8-12 hard drives.
If you are only doing say (5000,10000) transactions and hour or somewhere in between
you may get away with running vacuum in an off peak time.
Sincerely,
Joshua D. Drake
Thank you in advance,
Laimutis Nedzinskas Reykjavik, Iceland
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
-- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
