Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FileFormat API makes it hard to avoid round trips #13720

Open
gatesn opened this issue Dec 10, 2024 · 0 comments
Open

FileFormat API makes it hard to avoid round trips #13720

gatesn opened this issue Dec 10, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@gatesn
Copy link

gatesn commented Dec 10, 2024

Is your feature request related to a problem or challenge?

The FileFormat trait has infer_schema and infer_stats calls that are given ObjectMetas, and then afterwards the create_physical_plan call returns an ExecutionPlan.

First the ObjectMeta has a required size, implying either we externally know the object size or a HEAD request is made, even though we are often able to make a relative request from the end of the object to read stats + metadata.

The infer_schema and infer_stats both independently open and read the file metadata (at least in the Parquet implementation), and without a custom ParquetFileReaderFactory the ParquetExecBuilder will open and read the metadata a third time.

What would be the recommended way to carry the metadata through from the initial infer_schema call and reuse it for infer_stats and inside the execution plan? Should we have a session-scoped cache inside our FileFormat impl keyed by ObjectMeta? What would the recommended cache key be since that type doesn't impl Hash?

Would it be better to pass PartitionedFile into infer_schema and infer_stats so we can stash the metadata inside the extensions field?

Or should we avoid FileFormat entirely and go the route of a custom TableProvider?

Thank you for your thoughts!

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional context

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant