Re: hashjoins vs. Bloom filters (yet again) - Mailing list pgsql-hackers

On Wed, Jun 3, 2026 at 5:21 AM Oleg Bartunov <obartunov@postgrespro.ru> wrote:
> For a plain heap scan this may mostly save hash probes. But with zone/chunk-oriented storage, where chunks have
dictionaries,min/max metadata, Bloom summaries, or tenant ranges, the same runtime filter can skip whole chunks. That
isthe part I find most interesting: turning join-derived knowledge into scan-level pruning, against the normal
directionof data flow. 
>
> Bloom is just one carrier for that knowledge. The real feature is a pluggable runtime-filter mechanism that heap,
CustomScan,FDW, columnar/table AMs, partitioned storage, or chunk/cold storage can consume at the level they
understand.

+1. I think it's fine if the optimizer and executor decide to do
things strictly with Bloom filters, if that turns out to be a good
technique. But if we're talking about pushing things down into table
AM we should try to be more general.

Or at least, that's my current thinking.

--
Robert Haas
EDB: http://www.enterprisedb.com