Re: Seeking reason behind performance gain in 12 with HashAggregate

From: Shira Bezalel <shira(at)sfei(dot)org>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Michael Lewis <mlewis(at)entrata(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Seeking reason behind performance gain in 12 with HashAggregate
Date: 2020-01-13 21:45:55
Message-ID: CAE0KEwEyMhS85CcUJyom6QQ4VtSn6bwxiz-VoBpRe4DWw-12CQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Thanks Tomas. I ran a vacuum full on the 9.6 table -- still no difference
in the query plan. The shared buffers hit went up slightly to 36069.

Shira

On Mon, Jan 13, 2020 at 1:12 PM Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
wrote:

> On Mon, Jan 13, 2020 at 12:44:14PM -0800, Shira Bezalel wrote:
> >Hi Michael,
> >
> >I appreciate your question. I ran a vacuum analyze on the 9.6 table and it
> >yielded no difference. Same number of buffers were read, same query plan.
> >
>
> VACUUM ANALYZE won't shrink the table - the number of buffers will be
> exactly the same. You need to do VACUUM FULL, but be careful as that
> acquires exclusive lock on the table.
>
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

--
Shira Bezalel
Database Administrator & Desktop Support Manager
San Francisco Estuary Institute
www.sfei.org
Ph: 510-746-7304

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tomas Vondra 2020-01-13 22:14:11 Re: Bad query plan when you add many OR conditions
Previous Message Tomas Vondra 2020-01-13 21:11:56 Re: Seeking reason behind performance gain in 12 with HashAggregate