Re: Macro customizable hashtable / bitmapscan & aggregation perf - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Macro customizable hashtable / bitmapscan & aggregation perf
Date
Msg-id 20161009233803.6zjackpbz2v2s4sw@alap3.anarazel.de
Whole thread Raw
In response to Re: Macro customizable hashtable / bitmapscan & aggregation perf  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: Macro customizable hashtable / bitmapscan & aggregation perf
Re: [HACKERS] Macro customizable hashtable / bitmapscan & aggregation perf
List pgsql-hackers
Hi,

Attached is an updated version of the patchset. The main changes are
- address most of Tomas' feedback
- address regression test output changes by adding explicit ORDER BYs,
  in a separate commit.
- fix issues around hash tables sized up to PG_UINT32_MAX
- fix a bug in iteration with "concurrent" deletions

> > We didn't really for dynahash (as it basically assumed a fillfactor of 1
> > all the time), not sure if changing it won't also cause issues.
> >
>
> That's a case of glass half-full vs. half-empty, I guess. If we assumed load
> factor 1.0, then I see it as accounting for load factor (while you see it as
> not accounting of it).

Well, that load factor is almost never achieved, because we'd have grown
since...  I added a comment about disregarding fill factor and growth
policy to estimate_hashagg_tablesize, which is actually the place where
it'd seemingly make sense to handle it.

Tomas, did you have time to run a benchmark?

I think this is starting to look good.


Regards,

Andres

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Relids in upper relations
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade documentation improvement patch