| 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
| 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 |