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  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Fixes for a couple of resource leaks
Следующее
От: Robert Haas
Дата:
Сообщение: Re: anole: assorted stability problems