Repository navigation
perf: preserve dictionaries for literal regex predicates - #27447
Rich-T-kid wants to merge 1 commit into
Conversation
|
run benchmark tpch tpcds clickbench_partitioned |
|
🤖 Benchmark running (GKE) | trigger CPU Details (lscpu)Comparing codex/dict-regex-suite-gate (7081eb6) to 73e0b03 (merge-base) diff Run configurationrun benchmark clickbench_partitioned
env:
DATAFUSION_EXECUTION_PARQUET_ENABLE_RLE_TO_DICTIONARY: "true"
DATAFUSION_RUNTIME_MEMORY_LIMIT: "32G"Results will be posted here when complete File an issue against this benchmark runner |
|
🤖 Benchmark running (GKE) | trigger CPU Details (lscpu)Comparing codex/dict-regex-suite-gate (7081eb6) to 73e0b03 (merge-base) diff Run configurationrun benchmark tpch
env:
DATAFUSION_EXECUTION_PARQUET_ENABLE_RLE_TO_DICTIONARY: "true"
DATAFUSION_RUNTIME_MEMORY_LIMIT: "32G"Results will be posted here when complete File an issue against this benchmark runner |
|
🤖 Benchmark running (GKE) | trigger CPU Details (lscpu)Comparing codex/dict-regex-suite-gate (7081eb6) to 73e0b03 (merge-base) diff Run configurationrun benchmark tpcds
env:
DATAFUSION_EXECUTION_PARQUET_ENABLE_RLE_TO_DICTIONARY: "true"
DATAFUSION_RUNTIME_MEMORY_LIMIT: "32G"Results will be posted here when complete File an issue against this benchmark runner |
|
🤖 Benchmark completed (GKE) | trigger Instance: Comparing codex/dict-regex-suite-gate (7081eb6) to 73e0b03 (merge-base) diff Run configurationrun benchmark tpch
env:
DATAFUSION_EXECUTION_PARQUET_ENABLE_RLE_TO_DICTIONARY: "true"
DATAFUSION_RUNTIME_MEMORY_LIMIT: "32G"CPU Details (lscpu)Details
Memory Pool PeaksPeak Base:
Pool accounting vs. process RSS Max pool peak is the largest reservation any single query in the run reached; peak RSS covers the whole invocation, including data loading and allocator retention, and the two high-water marks need not coincide in time. The gap is therefore an upper bound on what the pool did not account for, not a measurement of it.
Resource Usagetpch — base (merge-base)
tpch — branch
File an issue against this benchmark runner |
|
🤖 Benchmark completed (GKE) | trigger Instance: Comparing codex/dict-regex-suite-gate (7081eb6) to 73e0b03 (merge-base) diff Run configurationrun benchmark tpcds
env:
DATAFUSION_EXECUTION_PARQUET_ENABLE_RLE_TO_DICTIONARY: "true"
DATAFUSION_RUNTIME_MEMORY_LIMIT: "32G"CPU Details (lscpu)Details
Memory Pool PeaksPeak Base:
Pool accounting vs. process RSS Max pool peak is the largest reservation any single query in the run reached; peak RSS covers the whole invocation, including data loading and allocator retention, and the two high-water marks need not coincide in time. The gap is therefore an upper bound on what the pool did not account for, not a measurement of it.
Resource Usagetpcds — base (merge-base)
tpcds — branch
File an issue against this benchmark runner |
|
🤖 Benchmark completed (GKE) | trigger Instance: Comparing codex/dict-regex-suite-gate (7081eb6) to 73e0b03 (merge-base) diff Run configurationrun benchmark clickbench_partitioned
env:
DATAFUSION_EXECUTION_PARQUET_ENABLE_RLE_TO_DICTIONARY: "true"
DATAFUSION_RUNTIME_MEMORY_LIMIT: "32G"CPU Details (lscpu)Details
Memory Pool PeaksPeak Base:
Pool accounting vs. process RSS Max pool peak is the largest reservation any single query in the run reached; peak RSS covers the whole invocation, including data loading and allocator retention, and the two high-water marks need not coincide in time. The gap is therefore an upper bound on what the pool did not account for, not a measurement of it.
Resource Usageclickbench_partitioned — base (merge-base)
clickbench_partitioned — branch
File an issue against this benchmark runner |
|
Hosted benchmark result: this does not provide evidence for the literal-regex optimization. None of the required suites executes the changed binary regex operators:
Because no benchmark query enters this code path, none of the timing movement can be attributed to this patch. There is no clear evidence of an end-to-end speedup in the required suites, so I am closing the draft. |
Which issue does this PR close?\n\n- Part of #1178.\n\n## Rationale for this change\n\nLiteral binary regex predicates currently cast dictionary-encoded strings to flat arrays before evaluation. This repeats the same regex work for every key occurrence instead of evaluating dictionary values once.\n\nThis is a draft performance experiment. It is gated on the existing hosted TPC-H, TPC-DS, and partitioned ClickBench suites and will be closed if they do not show an attributable speedup.\n\n## What changes are included in this PR?\n\n- Preserve dictionary input through simplification for literal regex predicates.\n- Evaluate scalar regex patterns against dictionary values and reuse the original keys.\n- Compact oversized retained dictionaries before evaluation.\n- Add optimizer, physical-expression, and end-to-end plan tests.\n\nNo benchmark files or custom benchmark queries are added or changed.\n\n## What is the testing strategy?\n\n- cargo test -p datafusion-optimizer test_cast_preimage_dictionary_regex_literal --lib\n- cargo test -p datafusion-physical-expr expressions::binary --lib\n- cargo test -p datafusion --test core_integration dictionary_literal_regex_preserves_encoding\n- cargo clippy -p datafusion-optimizer -p datafusion-physical-expr -p datafusion --lib --tests -- -D warnings\n- cargo fmt --all -- --check\n- Full repository pre-push hook\n- Hosted TPC-H, TPC-DS, and partitioned ClickBench runs on the exact PR head\n\n## Are there any user-facing changes?\n\nLogical results are unchanged. Dictionary-encoded inputs can remain dictionary encoded through the physical regex predicate.