On Tue, Apr 25, 2017 at 12:45 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Andres Freund <and...@anarazel.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 <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

    Author: Álvaro Herrera, loosely based on a submission by Claudio Freire

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to