On Wed, Jun 3, 2026 at 5:21 AM Oleg Bartunov <[email protected]> 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
