Re: PG 10 release notes

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

On Tue, Apr 25, 2017 at 12:45 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 2017-04-24 23:37:42 -0400, Bruce Momjian wrote:
>>> I remember seeing those and those are normally details I do not put in
>>> the release notes as there isn't a clear user experience change except
>>> "Postgres is faster". Yeah, a bummer, and I can change my filter, but
>>> it would require discussion.
>
>> I think "postgres is faster" is one of the bigger user demands, so I
>> don't think that policy makes much sense. A large number of the changes
>> over the next few releases will focus solely on that. Nor do I think
>> past release notes particularly filtered such changes out.
>
> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2017-04-25 16:42:04 Re: pgbench tap tests & minor fixes
Previous Message Stephen Frost 2017-04-25 16:26:50 Re: pg_dump emits ALTER TABLE ONLY partitioned_table