Re: So I'm actually using the columns during merge join, basically I'm building
a bloom filter on the outer relation and filtering out data on the inner
relation of the join. I'm building the filter on the join keys
We had a whole implementation for Bloom filtering for hash inner join, complete
Hi,
(please don't top-quote on PG lists)
On 2022-06-27 19:29:34 +, Ma, Marcus wrote:
> So I'm actually using the columns during merge join, basically I'm building a
> bloom filter on the outer relation and filtering out data on the inner
> relation of the join. I'm building the filter on th
Hey Andres,
So I'm actually using the columns during merge join, basically I'm building a
bloom filter on the outer relation and filtering out data on the inner relation
of the join. I'm building the filter on the join keys, so the columns are being
used further up the execution tree. However,
Hi,
On 2022-06-27 19:00:44 +, Ma, Marcus wrote:
> If I understand correctly, when a Sequential Scan takes place, the ExecScan
> function (located in executor/execScan.c) does not retrieve all attributes
> per tuple in the TupleTableSlot and only retrieves the necessary attribute.
> So for e
Hey,
If I understand correctly, when a Sequential Scan takes place, the ExecScan
function (located in executor/execScan.c) does not retrieve all attributes per
tuple in the TupleTableSlot and only retrieves the necessary attribute. So for
example, let’s imagine we have a table t1 with 3 number
