Ühel kenal päeval, T, 2006-06-06 kell 13:53, kirjutas Christopher Browne: > >> We have triggers that fire is something interesting is found on insert. > >> We want this thing to run for a log time. > >> From the numbers, you can see the PostgreSQL database is VERY loaded. > >> Running VACUUM may not always be possible without losing data. > > > > why ? just run it with very friendly delay settings. > > "Friendly delay settings" can have adverse effects; it is likely to > make vacuum run on the order of 3x as long, which means that if you > have a very large table that takes 12h to VACUUM, "vacuum delay" will > increase that to 36h, which means you'll have a transaction open for > 36h. > > That'll be very evil, to be sure...
Not always. I know that it is evil in slony1 context, but often it *is* possible to design your system in a way where a superlong transaction is almost unnoticable. Long transactions are evil in case they cause some fast-changing table to grow its storage size several orders of magnitude, but if that is not the case then they just run there in backgroun with no ill effects, especially do-nothing transactions like vacuum. -- ---------------- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
