On 21 Aug 2003 at 16:22, Andrew Sullivan wrote:
> On Thu, Aug 21, 2003 at 09:10:34PM +0530, Shridhar Daithankar wrote:
> > Well, nothing can help if the database has dead tuples already.
> > Sometime somebody has to take time to run vacuum full and/or
> > database reload to get a clean state.
>
> But if you have a busy system, you'll have new dead tuples.
Yes. but if you have big enough FSM, you can afford them right? At least till
next vacuum runs..
>
> > Point I am trying to make is to tune FSM and autovacuum frequency
> > such that you catch all the dead tuples in RAM, which is
> > non-blocking operation at the expense of some CPU power. I am sure
> > 1 min autovacuum I suggested is waaay too aggressive for any
> > scheduled vacuum isn't it?
>
> Not for some cases. In (say) 40% write situation, you have _lots_ of
> dead tuples. Perhaps you can make the application more efficient,
> but that's not always an option (maybe you don't have the code).
Idea of autovacuum is to reduce load on vacuum full. If you set shared_buffers
higher and FSM properly for he update/delete load, autovacuum is expected to
catch most of the dead tuples in shared cache only. If it is successful in
doubling the frequency on vacuum full, that's a big win, isn't it?
Bye
Shridhar
--
QOTD: "It's sort of a threat, you see. I've never been very good at them myself, but I'm told they can be very
effective."
