Re: PG 10 release notes

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Claudio Freire <klaussfreire(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG 10 release notes
Date: 2017-04-25 17:11:32
Message-ID: 20170425171132.GT7513@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)alvh(dot)no-ip(dot)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.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-04-25 17:15:52 Re: pg_dump emits ALTER TABLE ONLY partitioned_table
Previous Message Serge Rielau 2017-04-25 17:09:37 Re: Cached plans and statement generalization