push_down_filter.slt into standalone sqllogictest files to reduce long-tail runtime (#20566)
## Which issue does this PR close? * Part of #20524 ## Rationale for this change `datafusion/sqllogictest/test_files/push_down_filter.slt` had grown into a large sqllogictest file. Since the sqllogictest runner parallelizes at **file granularity**, a single heavyweight file can become a straggler and dominate wall-clock time. This PR performs a non-invasive split of that file into smaller, self-contained `.slt` files so the runner can distribute work more evenly across threads, improving overall suite balance without changing SQL semantics or test coverage. ## What changes are included in this PR? * Removed the monolithic `push_down_filter.slt`. * Added new standalone sqllogictest files, each with the minimal setup/teardown required to run independently: * `push_down_filter_unnest.slt` — unnest filter pushdown coverage (including struct/field cases). * `push_down_filter_parquet.slt` — parquet filter pushdown + limit + cast predicate behavior + dynamic filter pushdown (swapped join inputs). * `push_down_filter_outer_joins.slt` — LEFT/RIGHT join and anti-join logical filter pushdown checks. * `push_down_filter_regression.slt` — regression coverage for issues #17188 and #17512, plus aggregate dynamic filter pushdown checks. * Updated scratch output paths to be file-scoped (e.g. `test_files/scratch/push_down_filter_parquet/...`) to reduce the chance of conflicts when tests execute in parallel. * Preserved all original query expectations and explain-plan assertions; changes are organizational only. ## Are these changes tested? Yes, with a python script to compare text blocks in the new slt files vs old single slt file. ``` python - <<'PY' import subprocess, re from collections import defaultdict, deque repo = '.' old_spec = '692a7cb67^:datafusion/sqllogictest/test_files/push_down_filter.slt' new_specs = [ 'HEAD:datafusion/sqllogictest/test_files/push_down_filter_outer_joins.slt', 'HEAD:datafusion/sqllogictest/test_files/push_down_filter_parquet.slt', 'HEAD:datafusion/sqllogictest/test_files/push_down_filter_regression.slt', 'HEAD:datafusion/sqllogictest/test_files/push_down_filter_unnest.slt', ] def git_show(spec): return subprocess.check_output(['git', '-C', repo, 'show', spec], text=True) def normalize_sql(sql): s = sql.strip().lower() s = re.sub( r"test_files/scratch/push_down_filter(?:_[^'\s;)/]+)?[^'\s;)]*", "test_files/scratch/__norm__", s, ) s = re.sub(r'\s+', ' ', s) return s def blocks(text): lines = text.splitlines() out = [] i = 0 while i < len(lines): m = lines[i].strip() if m.startswith('query '): i += 1 b = [] while i < len(lines) and lines[i].strip() != '----': if not lines[i].lstrip().startswith('#'): b.append(lines[i]) i += 1 sql = '\n'.join(b).strip() if sql: out.append(('query', normalize_sql(sql))) elif m.startswith('statement '): i += 1 b = [] while i < len(lines): s = lines[i].strip() if s == '': break if s.startswith('query ') or s.startswith('statement '): i -= 1 break if not lines[i].lstrip().startswith('#'): b.append(lines[i]) i += 1 sql = '\n'.join(b).strip() if sql: out.append(('statement', normalize_sql(sql))) i += 1 return out old_blocks = blocks(git_show(old_spec)) new_blocks = [] for s in new_specs: new_blocks.extend(blocks(git_show(s))) q = defaultdict(deque) for item in new_blocks: q[item].append(item) missing = 0 extra = 0 for item in old_blocks: if q[item]: q[item].popleft() else: missing += 1 for v in q.values(): extra += len(v) print(f'old_blocks={len(old_blocks)}') print(f'new_blocks={len(new_blocks)}') print(f'missing={missing}') print(f'extra={extra}') print(f'baseline={old_spec}') if missing != 0: raise SystemExit(1) PY ``` Output: ``` old_blocks=107 new_blocks=108 missing=0 extra=1 ``` The extra(1) is this statement block: set datafusion.explain.physical_plan_only = true; Why it shows as extra: In split files, it appears 3 times: push_down_filter_parquet.slt:21 push_down_filter_unnest.slt:21 push_down_filter_regression.slt:129 In the baseline monolithic file at e937cadbc^, it appears 2 times. So comparison reports 3 - 2 = extra 1. ## Are there any user-facing changes? No user-facing behavior changes. This is a test-suite organization/performance improvement only. ## Note before merging Revert e8369bb (it is a commit to trigger the CI extented tests for sqllogictest) ## LLM-generated code disclosure This PR includes LLM-generated code and comments. All LLM-generated content has been manually reviewed and tested.
Apache DataFusion
DataFusion is an extensible query engine written in Rust that uses Apache Arrow as its in-memory format.
This crate provides libraries and binaries for developers building fast and feature-rich database and analytic systems, customized for particular workloads. See use cases for examples. The following related subprojects target end users:
- DataFusion Python offers a Python interface for SQL and DataFrame queries.
- DataFusion Comet is an accelerator for Apache Spark based on DataFusion.
"Out of the box," DataFusion offers SQL and DataFrame APIs, excellent performance, built-in support for CSV, Parquet, JSON, and Avro, extensive customization, and a great community.
DataFusion features a full query planner, a columnar, streaming, multi-threaded, vectorized execution engine, and partitioned data sources. You can customize DataFusion at almost all points including additional data sources, query languages, functions, custom operators and more. See the Architecture section for more details.
Here are links to important resources:
- Project Site
- Installation
- Rust Getting Started
- Rust DataFrame API
- Rust API docs
- Rust Examples
- Python DataFrame API
- Architecture
What can you do with this crate?
DataFusion is great for building projects such as domain-specific query engines, new database platforms and data pipelines, query languages and more. It lets you start quickly from a fully working engine, and then customize those features specific to your needs. See the list of known users.
Contributing to DataFusion
Please see the contributor guide and communication pages for more information.
Crate features
This crate has several features which can be specified in your Cargo.toml.
Default features:
nested_expressions: functions for working with nested types such asarray_to_stringcompression: reading files compressed withxz2,bzip2,flate2, andzstdcrypto_expressions: cryptographic functions such asmd5andsha256datetime_expressions: date and time functions such asto_timestampencoding_expressions:encodeanddecodefunctionsparquet: support for reading the Apache Parquet formatsql: support for SQL parsing and planningregex_expressions: regular expression functions, such asregexp_matchunicode_expressions: include Unicode-aware functions such ascharacter_lengthunparser: enables support to reverse LogicalPlans back into SQLrecursive_protection: uses recursive for stack overflow protection.
Optional features:
avro: support for reading the Apache Avro formatbacktrace: include backtrace information in error messagesparquet_encryption: support for using Parquet Modular Encryptionserde: enable arrow-schema'sserdefeature
DataFusion API Evolution and Deprecation Guidelines
Public methods in Apache DataFusion evolve over time: while we try to maintain a stable API, we also improve the API over time. As a result, we typically deprecate methods before removing them, according to the deprecation guidelines.
Dependencies and Cargo.lock
Following the guidance on committing Cargo.lock files, this project commits
its Cargo.lock file.
CI uses the committed Cargo.lock file, and dependencies are updated regularly
using Dependabot PRs.