Re: hashjoins vs. Bloom filters (yet again)

On 7/14/26 15:28, Matheus Alcantara wrote:
> On Mon Jul 13, 2026 at 8:55 PM -03, Tomas Vondra wrote:
>> Which last patch you mean? The v4 creates the scan paths with filters at
>> the beginning of the planning, which seems exactly the opposite to the
>> post-processing approach. Which means it can change the join order, it
>> can change which join algorithms we selected, etc.
>>
>> The approach in v1 is what I'd call post-processing, as it made the
>> decisions in createplan, after everything else was already decided. It
>> could not change join order or join algorithms, it was entirely
>> opportunistic.
>>
>
> Sorry, that last paragraph was confusing — I didn't reread my reply
> before sending it. I mixed up the v1 and v4 implementations while
> writing it.
>
> What I actually meant to say is that v4 (and v5, as an evolution of v4,
> which I sent in my previous reply) seems like the way to go. Of course
> there's a lot to improve and think about, but the overall idea —
> creating paths with and without the pushed-down filters, accounting for
> them when costing the scan path, and letting the cost-based path
> selection decide which is better — makes sense to me. It consider the
> fact that pushing down filters is not free and it did not make EXPLAIN
> consufing with the expected x actual problem.
>

OK, thanks for the clarification.

>> Some engines may do that unconditionally in the post-planning phase. It
>> can't change the plan anyway, so why bother with costing, right? But
>> then they still do some cost/benefit decisions at execution time, either
>> when deciding to build the filters, or to disable filters that turn out
>> to be ineffective.
>>
>> As for the expected vs actual difference, I think this would be a big
>> issue, because it'd make EXPLAIN output utterly confusing. I don't think
>> I could convince myself to commit that into core ...
>>
>
> I definitely agree with this, it can lead to a lot of confusion, e.g.,
> "is the expected-vs-actual difference because of filter pushdown, or
> because the statistics are out of date?" So I'd also like to avoid that
> kind of behavior.
>

Agreed.

regards

--
Tomas Vondra