On Tue, Apr 25, 2017 at 2:11 PM, Bruce Momjian <br...@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 <alvhe...@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_7zqx8l9gchdsqkydo1tguh791z6py...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
