>- Q. Bad knews that VACUUM must eventually scan every row(in fact, every row
>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?
>
>
>
On heavily used databases (over 100,000 transactions an hour), vacuum is
a killer and
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 - jd@commandprompt.com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL