Re: Automatic free space map filling
От | Csaba Nagy |
---|---|
Тема | Re: Automatic free space map filling |
Дата | |
Msg-id | 1141376884.3327.58.camel@coppola.muc.ecircle.de обсуждение исходный текст |
Ответ на | Re: Automatic free space map filling ("Matthew T. O'Connor" <matthew@zeut.net>) |
Ответы |
Re: Automatic free space map filling
|
Список | pgsql-hackers |
> Are you running 8.1? If so, you can use autovacuum and set per table > thresholds (read vacuum aggressivly) and per table cost delay settings > so that the performance impact is minimal. If you have tried 8.1 > autovacuum and found it unhelpful, I would be curious to find out why. Yes, I'm running 8.1, and I've set up per table auto-vacuum settings :-) And I lowered the general thresholds too. Generally autovacuum is very useful from my POV, and in particular the per table settings are so. But the problem I have is not the performance impact of the vacuum itself, but the impact of the long running transaction of vacuuming big tables. I do have big tables which are frequently updated and small tables which are basically queue tables, so each inserted row will be updated a few times and then deleted. Those queue tables tend to get huge unvacuumable dead space during any long running transaction, and vacuum on the big tables is such a long running transaction. And I have a few of them, and one is in particular very busy (a task table, all activities go through that one). Now when the queue tables get 1000 times dead space compared to their normal size, I get performance problems. So tweaking vacuum cost delay doesn't buy me anything, as not vacuum per se is the performance problem, it's long run time for big tables is. Cheers, Csaba.
В списке pgsql-hackers по дате отправления: