apache / apache/datafusion

Represent Hive/value partitioning without claiming Partitioning::Hash

Open
#23,436 1 comment 1 reaction 0 assignees View on GitHub
enhancement
Dominant language
Rust
Stars
9.3k
Forks
2.4k
Avg merge
3d 7h
Merged PRs (30d)
344

Description

### Is your feature request related to a problem or challenge?

Follow-up from https://github.com/apache/datafusion/pull/23189

File scans for Hive/value-partitioned data currently represent their output partitioning as `Partitioning::Hash` on the partition columns. This lets the optimizer avoid repartitioning for key-partitioned operators, but the data was
not actually assigned to partitions by DataFusion's hash partitioner.

This makes `Partitioning::Hash` carry multiple meanings:

- DataFusion hash partitioning with a particular hash implementation / seed
- another hash implementation / seed
- Hive/value-based file grouping by partition column values
- potentially other source-defined key partitioning methods

These partitioning methods can all provide key colocation, but they are not necessarily co-partitioned by partition index. Treating them all as `Partitioning::Hash` can make later optimizer decisions and dynamic filtering
decisions brittle or incorrect if they rely on partition compatibility.

### Describe the solution you'd like

Discuss and design a more precise representation for value-based physical partitioning. Possible directions from the PR discussion include:

- add a new `Partitioning::Value` / `ValuePartitioned` variant
- represent Hive/value partitioning as `Partitioning::Range` when values and ordering are available
- make the partitioning method explicit, e.g. hash algorithm/seed vs column value grouping
- explore whether `Partitioning` should become extensible for source-defined partitioning methods

The design should distinguish:

- satisfying a `Distribution::KeyPartitioned` requirement, where key colocation may be enough
- proving co-partitioning / partition-index compatibility between two inputs, where the exact partitioning method and value-to-partition mapping matter

### Describe alternatives you've considered

_No response_

### Additional context

Related issues and PRs:

- #19090
- #23099
- #23236
- #23266
- #23189

Relevant review thread:

- https://github.com/apache/datafusion/pull/23189#discussion_r3544046751
- https://github.com/apache/datafusion/pull/23189#discussion_r3544133348
- https://github.com/apache/datafusion/pull/23189#discussion_r3549863005
- https://github.com/apache/datafusion/pull/23189#discussion_r3549906872
- https://github.com/apache/datafusion/pull/23189#discussion_r3554849635

CC @gene-bordegaray @alamb @gabotechs @jayshrivastava

Contributor guide

Open the contributing guide

Research direction

Start with the Partitioning and Distribution discussion in this issue and the linked PR #23189, including its review thread and related issues #19090, #23099, #23236, and #23266. Compare the requirements for key colocation versus co-partitioning and partition-index compatibility. Done means the design precisely distinguishes Hive/value partitioning from DataFusion hash partitioning and records how optimizer decisions should use each distinction.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend-api-design, data-engineering, distributed-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.