On Tue, Apr 25, 2017 at 2:11 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Tue, Apr 25, 2017 at 01:37:13PM -0300, Claudio Freire wrote:
>> > I think it has been pretty common to accumulate a lot of such changes
>> > into generic entries like, say, "speedups for hash joins". More detail
>> > than that simply isn't useful to end users; and as a rule, our release
>> > notes are too long anyway.
>>
>> In that spirit, the truncation speedups it seems are missing:
>>
>> Might be summarized simply as:
>>
>> Vacuum truncation has been sped up for rotating media, sometimes
>> considerably (up to five times in certain configurations).
>>
>> Full commit, for reference:
>>
>> commit 7e26e02eec90370dd222f35f00042f8188488ac4
>> Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
>> Date: Mon Jan 23 12:55:18 2017 -0300
>>
>> Prefetch blocks during lazy vacuum's truncation scan
>>
>> Vacuum truncation scan can be sped up on rotating media by prefetching
>> blocks in forward direction. That makes the blocks already present in
>> memory by the time they are needed, while also letting OS read-ahead
>> kick in.
>>
>> The truncate scan has been measured to be five times faster than without
>> this patch (that was on a slow disk, but it shouldn't hurt on fast
>> disks.)
>>
>> Author: Álvaro Herrera, loosely based on a submission by Claudio Freire
>> Discussion:
>> https://postgr.es/m/CAGTBQpa6NFGO_6g_y_7zQx8L9GcHDSQKYdo1tGuh791z6PYgEg@mail.gmail.com
>
> I don't think this warrants inclusion in the release notes for reasons
> already discussed. The vacuum truncation operation is a rare one and
> an implementation detail.
\_(0_0)_/
As you wish.
Though if I wasn't already aware of it, I would like to know, because
it's been a source of trouble in the past.
