Ü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
