Re: hashjoins vs. Bloom filters (yet again)

On Wed, Jun 3, 2026 at 5:21 AM Oleg Bartunov <obartunov(at)postgrespro(dot)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 is the part I find most interesting: turning join-derived knowledge into scan-level pruning, against the normal direction of 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