Re: [HACKERS] PG 10 release notes
От | Claudio Freire |
---|---|
Тема | Re: [HACKERS] PG 10 release notes |
Дата | |
Msg-id | CAGTBQpYut-V+no4DZqkJMqCFsYqS5abks7dfbMqb-rjUmauTTg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] PG 10 release notes (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: [HACKERS] PG 10 release notes
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: