Re: optimizing vacuum truncation scans

On Thu, Jul 16, 2015 at 10:17 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Thu, Jul 16, 2015 at 11:21 AM, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
> wrote:
>
>>
>> Here I attached updated patches,
>> 1) without prefetch logic.
>> 2) with combined vm and prefetch logic.
>>
>
> I think it is better to just get the first patch in as that in itself is a
> clear win and then we can evaluate the second one (prefetching during
> truncation) separately. I think after first patch, the use case for doing
> prefetch seems to be less beneficial and I think it could hurt by loading
> not required pages (assume you have prefetched 32 pages and after
> inspecting first page, it decides to quit the loop as that is non-empty page
> and other is when it has prefetched just because for page the visibility map
> bit was cleared, but for others it is set) in OS buffer cache.

Yes, in the above cases, the prefetch is an overhead. I am not sure
how frequently such
scenarios occur in real time scenarios.

> Having said that, I am not against prefetching in this scenario as that
> can help in more cases then it could hurt, but I think it will be better
> to evaluate that separately.

Yes, the prefetch patch works better in cases, where majorly the first
vacuum skips
the truncation because of lock waiters. If such cases are more in real
time scenarios,
then the prefetch patch is needed.

Regards,
Hari Babu
Fujitsu Australia