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-31 18:25:47
Message-ID: 0495ba1c-32ff-4410-84f6-d3422a66c668@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 31/07/26 11:33, Tomas Vondra wrote:
>>> We could also agree on maintaining a shared branch somewhere, and post
>>> new patch versions to -hackers from time to time. That's what we did for
>>> index prefetching, and I think it worked. The one risk is it can move
>>> the discussion off-list too, so we'd need to be careful about that.
>>>
>>
>> Yeah, I think that it's a good idea. Do you mind sharing on github?
>>
>
> WFM. What's you github handle? I'll make you a collaborator, so that you
> can push to the shared branch.
>

mattheusv

>>> 1) The timings I see on TPC-H 10GB are much lower. I mean, for me Q3
>>> takes ~5s on master, while for you it seems to take ~100s. Similarly for
>>> the other queries. What kind of hardware / build are you using?
>>>
>>
>> Yeah, my machine seems much slower compared with your. I'm using a
>> MacBook Pro M3 with debug symbols and asserts enabled. I tried to not
>> make the machine busy while running the tests to not effect the
>> execution time but it seems it didn't help to much.
>>
>
> I don't think M3 is an order of magnitude slower than my systems. Debug
> symbols are fine, but asserts make the builds useless for any sort of
> performance comparisons. It does not affects the code evenly, an
> expensive assert can massively skew the results, etc.
>

Yeah, make sense. I'll disable asserts when running the next tests.
Thanks for the call.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vladlen Popolitov 2026-07-31 18:27:22 Re: zic: fix PostgreSQL build failure on filesystems without hard link support
Previous Message David K 2026-07-31 18:15:08 Re: Bug: XLogReader mishandles oversized multi-page xl_tot_len (potential memory corruption)