On Wed, Feb 11, 2009 at 10:03 PM, Grzegorz Jaśkiewicz <gryz...@gmail.com> wrote: > On Wed, Feb 11, 2009 at 2:57 PM, Rajesh Kumar Mallah > <mallah.raj...@gmail.com> wrote: > >>> vacuum_cost_delay = 150 >>> vacuum_cost_page_hit = 1 >>> vacuum_cost_page_miss = 10 >>> vacuum_cost_page_dirty = 20 >>> vacuum_cost_limit = 1000 >>> autovacuum_vacuum_cost_delay = 300 >> >> why is it not a good idea to give end users control over when they >> want to run it ? > > Effectively, you have control over autovacuum via these params. > You have to remember, that autovacuum doesn't cost much, and it makes > planner know more about data. > It's not there to clean up databases, as you might imagine - it is > there to update stats, and mark pages as free. > > So make sure you tweak that config fist, because I have a funny > feeling that you just think that vacuuming bogs down your machine, and > _can_ be turned off without any bad consequences, which is simply not > true.
our usage pattern is such that peak activity (indicated by load average) during day time is 10 times during night hours. Autovacuum just puts more pressure to the system. If less stressing version is used then it shall take longer to complete one cycle, which would mean less performance for longer time . Less performance queues up queries and encourages people to re submit their queries which again adds to bogging up the system. In our case i feel the hardware is bit underscaled as compared to load thats why i think running in lean hours is best of both worlds no performance sacrifices and intelligent vacuuming. regds -- mallah. > > > -- > GJ > -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
