Re: optimizing vacuum truncation scans
От | Haribabu Kommi |
---|---|
Тема | Re: optimizing vacuum truncation scans |
Дата | |
Msg-id | CAJrrPGfusUbZf0Yg==tXQ0so55Y_4yXid=-MihrgYYykir4FNg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: optimizing vacuum truncation scans (Haribabu Kommi <kommi.haribabu@gmail.com>) |
Ответы |
Re: optimizing vacuum truncation scans
|
Список | pgsql-hackers |
On Thu, Jul 9, 2015 at 5:36 PM, Haribabu Kommi <kommi.haribabu@gmail.com> wrote: > > I will do some performance tests and send you the results. Here are the performance results tested on my machine. Head vm patch vm+prefetch patch First vacuum 120sec <1sec <1sec second vacuum 180 sec 180 sec 30 sec I did some modifications in the code to skip the vacuum truncation by the first vacuum command. This way I collected the second vacuum time taken performance. I just combined your vm and prefetch patch into a single patch vm+prefetch patch without a GUC. I kept the prefetch as 32 and did the performance test. I chosen prefetch based on the current buffer access strategy, which is 32 for vacuum presently instead of an user option. Here I attached the modified patch with both vm+prefetch logic. I will do some tests on a machine with SSD and let you know the results. Based on these results, we can decide whether we need a GUC or not? based on the impact of prefetch on ssd machines. Regards, Hari Babu Fujitsu Australia
Вложения
В списке pgsql-hackers по дате отправления: