NoahKusaba opened a new issue, #2726: URL: https://github.com/apache/datafusion-ballista/issues/2726
**Is your feature request related to a problem or challenge? Please describe what you are trying to do.** Follow-up from [this review comment](https://github.com/apache/datafusion-ballista/pull/2638#discussion_r4431883840) on #2638. `ballista-iceberg` pins each catalog-backed Iceberg table to the version its catalog serves when a query is planned, so every scan in the query, such as each side of a self-join, reads the same version, and encoding plans needs no I/O. A view stores a planned query, so it keeps the version from when it was created. In single-process DataFusion, a view over `IcebergCatalogTableProvider` picks up new commits each time it runs. On Ballista it doesn't, so the same code gives different results once it moves to Ballista. The same goes for a `DataFrame` or a Flight SQL prepared statement run more than once. This is documented as a limitation in #2638. **Describe the solution you'd like** Re-plan a view from its SQL each time a query uses it, as Spark does: Spark stores a view's SQL text and analyzes it again for every query that references it, so its tables resolve to their current versions. DataFusion's `ViewTable` already keeps the SQL it was created from (`ViewTable::definition()`). `ballista-iceberg`'s pinning schema wrapper, which already sees every table lookup, could re-plan a view that has a definition when it's looked up, pinning its Iceberg tables to the versions current at that time. Open questions: - `SchemaProvider::table` gets no session state to plan the SQL with. - A view created without SQL, such as from a `DataFrame`, has no definition to re-plan. - Whether reused `DataFrame`s and prepared statements should re-plan too, and how. **Describe alternatives you've considered** - Pin tables when the scheduler receives the plan rather than when the client plans it. Views would still hold the client's plan, and encoding would need catalog I/O. - Leave it as a documented limitation, as #2638 does. **Additional context** Part of #2174. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
