Re: optimizing vacuum truncation scans

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: optimizing vacuum truncation scans
Date: 2015-07-13 02:06:55
Message-ID: CAJrrPGfusUbZf0Yg==tXQ0so55Y_4yXid=-MihrgYYykir4FNg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 9, 2015 at 5:36 PM, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)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

Attachment Content-Type Size
vac_trunc_trust_vm_and_prefetch.patch application/octet-stream 4.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-07-13 02:12:45 Re: anole: assorted stability problems
Previous Message Michael Paquier 2015-07-13 01:36:44 Re: Fixes for a couple of resource leaks