Re: Why vacuum?
От | Daniele Orlandi |
---|---|
Тема | Re: Why vacuum? |
Дата | |
Msg-id | 3A380A61.7DCEDCBF@orlandi.com обсуждение исходный текст |
Ответ на | Why vacuum? (bpalmer <bpalmer@crimelabs.net>) |
Ответы |
Re: Why vacuum?
|
Список | pgsql-hackers |
bpalmer wrote: > > I noticed the other day that one of my pg databases was slow, so I ran > vacuum on it, which brought a question to mind: why the need? I looked > at my oracle server and we aren't doing anything of the sort (that I can > find), so why does pg need it? Any info? Hi, I'm one of the people beeing slightly bitten by the current vacuum behaviour :), so i take the chance to add my suggestions to this question. FWIW, my thought is about a vacuumer process that, in background, scans each table for available blocks (for available I mean a block full of deleted rows whose tid is commited) and fills a cache of those blocks available to the backends. Whenever a backend needs to allocate a new block it looks for a free block in the cache, if it finds any, it can use it, else it proceeds as usual appending the block at the tail. The vacuumer would run with a very low priority, so that it doesn't suck precious CPU and I/O when the load on the machine is high. A small flag on each table would avoid the vacuumer to scan the table if no empty block is found and no tuple has been deleted. Ok, now tell me where this is badly broken :)) Just my .02 euro :) Bye! -- Daniele Orlandi
В списке pgsql-hackers по дате отправления: