Evaluate LIKE over filtered inputs filter-first#8580
Conversation
Signed-off-by: Nicholas Gates <nick@nickgates.com>
Merging this PR will not alter performance
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ❌ | Simulation | copy_nullable[65536] |
1 ms | 1.4 ms | -24.25% |
| ❌ | Simulation | copy_non_nullable[65536] |
908.4 µs | 1,089 µs | -16.58% |
| ⚡ | Simulation | encode_varbin[(1000, 4)] |
157 µs | 138.3 µs | +13.52% |
| ⚡ | Simulation | encode_varbin[(1000, 2)] |
156.1 µs | 138 µs | +13.14% |
| ⚡ | Simulation | encode_varbin[(1000, 8)] |
157.3 µs | 139.1 µs | +13.05% |
| ⚡ | Simulation | encode_varbin[(1000, 32)] |
162.5 µs | 145.2 µs | +11.85% |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing ngates/onpair-split-2-like-filter-first (2b5ece2) with develop (2a19323)
Footnotes
-
4 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩
This is an interesting experiment because it demonstrates when we do/don't want filter push-down and how it largely depends on the cost of the expression...