Re: hashjoins vs. Bloom filters (yet again)

On 8/19/26 17:05, Bruce Momjian wrote:
> On Mon, Jul 13, 2026 at 10:17:28PM +0200, Tomas Vondra wrote:
>> On 7/7/26 20:39, Tomas Vondra wrote:
>>
>> ...
>>
>> 1) filter types
>>
>> The main thing shared by most of the databases is the types of filters
>> supported. Most of the databases support these three kinds of filters:
>>
>> * Bloom filters
>> * exact "IN" list of values
>> * min/max range filter
>>
>> There are some differences in how the filter type gets selected,
>> sometimes the filter is "hybrid" and combines e.g. Bloom + min/max. Most
>> of these differences seem minor, and depend on how exactly the database
>> uses the filter.
>
> 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.

regards

[1]
https://www.postgresql.org/message-id/flat/CAHueFRVqNuKQ0%2BLQPZVwMgJ%2BLpuTbZ21%2BztwFbgPhBf9maFGYA%40mail.gmail.com

--
Tomas Vondra