Re: Seeking reason behind performance gain in 12 with HashAggregate

From: Shira Bezalel <shira(at)sfei(dot)org>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Seeking reason behind performance gain in 12 with HashAggregate
Date: 2020-01-14 00:11:48
Message-ID: CAE0KEwHMVVg2O0eDfk=1p7eg=76_h6eZbqNOKH08EkZ7ySjrkw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, Jan 13, 2020 at 2:15 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> On 2020-Jan-13, Shira Bezalel wrote:
>
> > Hi All,
> >
> > I'm testing an upgrade from Postgres 9.6.16 to 12.1 and seeing a
> > significant performance gain in one specific query. This is really great,
> > but I'm just looking to understand why.
>
> pg12 reads half the number of buffers. I bet it's because of this change:
>
> commit 4d0e994eed83c845a05da6e9a417b4efec67efaf
> Author: Stephen Frost <sfrost(at)snowman(dot)net>
> AuthorDate: Tue Apr 2 12:35:32 2019 -0400
> CommitDate: Tue Apr 2 12:35:32 2019 -0400
>
> Add support for partial TOAST decompression
>
> When asked for a slice of a TOAST entry, decompress enough to return
> the
> slice instead of decompressing the entire object.
>
> For use cases where the slice is at, or near, the beginning of the
> entry,
> this avoids a lot of unnecessary decompression work.
>
> This changes the signature of pglz_decompress() by adding a boolean to
> indicate if it's ok for the call to finish before consuming all of the
> source or destination buffers.
>
> Author: Paul Ramsey
> Reviewed-By: Rafia Sabih, Darafei Praliaskouski, Regina Obe
> Discussion:
> https://postgr.es/m/CACowWR07EDm7Y4m2kbhN_jnys%3DBBf9A6768RyQdKm_%3DNpkcaWg%40mail.gmail.com
>
> --
> Álvaro Herrera https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

That sounds like a possibility. Thanks Alvaro.

Shira

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Thomas Kellerer 2020-01-14 08:01:30 Re: Bad query plan when you add many OR conditions
Previous Message Alvaro Herrera 2020-01-13 22:15:11 Re: Seeking reason behind performance gain in 12 with HashAggregate