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