Re: optimizing vacuum truncation scans

On 3 August 2015 at 17:18, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:

> That does still leave the prefetch technique, so all is not lost.
>>
>> Can we see a patch with just prefetch, probably with a simple choice of
>> stride? Thanks.
>>
>
> I probably won't get back to it this commit fest, so it can be set to
> returned with feedback. But if anyone has good ideas for how to set the
> stride (or detect that it is on SSD and so is pointless to try) I'd love to
> hear about them anytime.
>

I've Returned With Feedback, as you suggest.

Given your earlier numbers, I'd just pick a constant value of 128, to keep
it simple. That balances out the various factors of small/large tables and
the uncertainty that we will be able to truncate the whole chunk of blocks.
I'd like to see tests on SSD before commit, but I hope and expect the
slightly negative results with SSD won't be substantiated on larger tests.

Kept simple, its a patch with a clear win in a restricted use case and I
would be happy to commit that sometime in the future.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services