Re: Buglist
От | Shridhar Daithankar |
---|---|
Тема | Re: Buglist |
Дата | |
Msg-id | 3F4609E5.1170.4CE7521@localhost обсуждение исходный текст |
Ответ на | Re: Buglist (Andrew Sullivan <andrew@libertyrms.info>) |
Ответы |
Re: Buglist
|
Список | pgsql-general |
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."
В списке pgsql-general по дате отправления: