Re: hashjoins vs. Bloom filters (yet again)

On 8/19/26 21:25, Bruce Momjian wrote:
> On Wed, Aug 19, 2026 at 07:31:18PM +0200, Tomas Vondra wrote:
>> On 8/19/26 17:05, Bruce Momjian wrote:
>>> One topic that came up in the Pittsburgh AI Workshop was the idea of
>>> combining indexes. For example, right now, all indexes point to heap,
>>> and we usually go from index to heap. We can combine indexes using
>>> bitmap scans of heap tids. Would there be any value of improving our
>>> ability to combine indexes beyond bitmap scans?
>>>
>>
>> Are you describing something like this [1]? That is, ability to build a
>> bitmap (from bitmap index scan), and pass it into an index scan, so that
>> it can benefit from the selective bitmap filter and ordering of the
>> regular index scan?
>>
>> I think that's an interesting idea / scan variant, skipping a possibly
>> expensive Sort. But I don't quite see how is that related to the topic
>> of this thread? It transfers predicate within a single scan (from one
>> index to the other), while the hashjoin bloom pushdown "transfers"
>> predicates between different plan nodes, possibly very distant.
>
> Yeah, not sure what I am asking. It was just a thought that maybe more
> flexible index combining can be helpful.
>

I agree, but I think it's mostly orthogonal to what this thread is
about. I mean, maybe the plan below Hash would benefit from a scan
combining indexes like this, but for the filter (built "on" the
hashtable) that's transparent.

We could also push the filters to this scan node, but then it's not
different from other scans. Although, it may not be entirely clear to
which of the scans to push it - but I realize we may already have that
issue with the Bitmap Heap Scan / Bitmap Index Scan.

So I still think it's a mostly independent feature.

--
Tomas Vondra