Re: optimizing vacuum truncation scans

From: Qingqing Zhou <zhouqq(dot)postgres(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: optimizing vacuum truncation scans
Date: 2015-04-20 19:45:12
Message-ID: CAJjS0u1S5UrWhR8fkia2C=ybfgf+jEw=0RnZuNCUO=F830F7hQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Apr 19, 2015 at 7:09 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> I did literally the simplest thing I could think of as a proof of concept patch, to see if it would actually fix things. I just jumped back a certain number of blocks occasionally and prefetched them forward, then resumed the regular backward scan.
IIRC, this patches introduces optional prefetch for the backward scan
where file system prefetch may not work well. The result is promising!

> Also, what would be the best way to drill a hole through bufmgr.c into md.c so that the prefetch could specify an entire range, rather than looping over each individual block?
>
Different from mdread(), which requires a buffer in argument.
Extending mdprefetch() looks natural and safe to me. This shall also
layout a foundation for other scan style optimizations.

> What would have to be done to detect people running on SSD and disable the feature, if anything?
>
There are other call sites of prefetch - so this shall be a topic not
just for this optimization.

Regards,
Qingqing

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2015-04-20 19:48:08 Re: Turning off HOT/Cleanup sometimes
Previous Message Peter Eisentraut 2015-04-20 19:43:36 Re: [pgsql-packagers] Palle Girgensohn's ICU patch