Re: Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)
Date: 2016-11-23 08:33:51
Message-ID: 20161123083351.5vramz52nmdokhzz@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2016-11-18 08:00:40 -0500, Robert Haas wrote:
> On Tue, Nov 15, 2016 at 2:28 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > I've a working fix for this, and for a similar issue Robert found. I'm
> > still playing around with it, but basically the fix is to make the
> > growth policy a bit more adaptive.
>
> Any chance you can post a patch soon?

Here's my WIP series addressing this and related problems. With this
we're again noticeably faster than the dynahash implementation, in both
the case here, and the query you brought up over IM.

This definitely needs some more TLC, but the general approach seems
good. I particularly like that it apparently allows us to increase the
default fillfactor without much downside according to my measurements.

Greetings,

Andres Freund

Attachment Content-Type Size
0001-Resize-simplehash.h-table-in-case-of-long-runs.patch text/x-patch 2.2 KB
0002-Signal-when-a-master-backend-is-doing-parallel-work.patch text/x-patch 3.9 KB
0003-Use-different-hash-IVs-for-tuplehash-tables-in-paral.patch text/x-patch 2.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2016-11-23 09:15:35 Re: [RFC] Should we fix postmaster to avoid slow shutdown?
Previous Message Vladimir Svedov 2016-11-23 08:08:53 Re: postgres 9.3 postgres_fdw ::LOG: could not receive data from client: Connection reset by peer