Daniël Heres
Daniël Heres
It seems in some cases it's faster: ``` ┏━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┓ ┃ Query ┃ topk-dynamic-filter ┃ topk-filters ┃ Change ┃ ┡━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━┩ │ Q1 │ 16.17 ms │ 16.89 ms │ no change...
Hm my earlier benchmarks didn't seem correct. not sure where the earlier run came from 🤔
In hindsight I think actually another fact that we don't see topk being as effective with more partitions is that spreading them over partitions will essentially make `topk(n)` into a...
(Removed a non-working proposal). I am wondering if we can somehow synchronize the values in the heap efficiently in order to make the filter for a `topk(n*partitions)` as efficient as...
> > Hm my earlier benchmarks didn't seem correct. not sure where the earlier run came from 🤔 > > What do the current ones show? Not much improvement? Yes...
> We could try a shared heap. It might work? I guess it will be a sort of balance between lock contention and better selectivity. Maybe we can balance it...
I am taking a look now, see if I can find a thing
I believe it should also be possible to share the `Arc` within the created `PhysicalExpr`. This avoids to build a bloom filter. We already have the full table in memory,...
2. Easier to serialize across the wire Yeah that part is of course true (especially larger tables you probably want to avoid sending over the network). the `1. More performant...