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 PR has been marked as stale because it has been open for 14 days with no activity. Please comment or remove the stale label if you wish to keep it active, otherwise it will be closed in 7 days |
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...