Re: hashjoins vs. Bloom filters (yet again)

From: "Matheus Alcantara" <matheusssilv97(at)gmail(dot)com>
To: "Tomas Vondra" <tomas(at)vondra(dot)me>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: hashjoins vs. Bloom filters (yet again)
Date: 2026-07-23 16:09:18
Message-ID: DK62XNJZ2GCO.2D7976JG0OSWO@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu Jul 23, 2026 at 9:02 AM -03, Tomas Vondra wrote:
> On 7/21/26 18:24, Tomas Vondra wrote:
>> ...
>>
>> FWIW I'm running some tests on TPC-H, to see which queries would benefit
>> from this, how much, if there are issues, etc. Should have some numbers
>> later this week.
>>
> Here's some results for TPC-H scale 10 and 50 (so relatively small, but
> manageable on my test systems). I used the same schema/indexes as usual.
> There may be a better schema, but what matters is the impact of enabling
> Bloom filters.
>
> The PDF shows results for the 22 TPC-H queries, for combinations of a
> couple parameters:
>
> - scale: 10GB vs. 50GB
> - cold vs. warmed-up
> - buffered I/O vs. direct I/O
> - 0 vs. 4 parallel workers
>
> The last four columns compare the runs with filters enabled vs.
> disabled. Green = good/faster.
>
> Overall, the results are pretty good. There's 5-6 queries with ~25%
> speedup, Q9 gets ~5x faster (10x with direct I/O). There's a bit of
> difference depending on the scale, direct I/O, etc.
>
> Of course, this mostly ignores the planning overhead. It's analytics
> benchmark, with multi-second queries, and the queries are relatively
> simple, so there's not that many possible filters.
>
> But overall it seems like a good result for a WIP patch. There are no
> visible regressions - it's all within noise, considering there was a
> single run per query / parameters.
>

Yeah, it looks good numbers at this stage, thanks for sharing.

FWIW I'm working on implementing the paper heuristics on top of now v7.
Once I have something I'll share and I'll also run some benchmarks
similar to what you've shared here so we can compare the results.

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zsolt Parragi 2026-07-23 16:26:16 Re: [PATCH] Use ssup_datum_*_cmp for int2, oid, and oid8 sort support
Previous Message Antonin Houska 2026-07-23 15:23:33 Re: Remove redundant DISTINCT when GROUP BY already guarantees uniqueness