> 1. Can the batch loading interface support quick failure? If the engine hopes to fail immediately upon encountering a single table during the planning process, there is no need to load subsequent tables.
This behavior aligns with the current wording in the design doc, as the status code for individual table in the response payload only covers "Ok", "NotFound", "NotModified". Any other failure (like authorization) will cause the whole request to fail. This section <https://docs.google.com/document/d/1VW5hgaaajRWtp5KbOU3s83YyoyPi5WOSvHtoJ_yXzJs/edit?tab=t.0> talked about partial failure for authorization issues. This is probably worth discussing. Not sure what others think. > 2. Is it necessary to support time travel configuration at the table level? In time travel queries, the engine may need to load specific versions of table metadata. Time travel is handled entirely on the client side. Catalog just returns the snapshot history in the table. But if you are talking about the multi-table multi-statement transaction, that is mentioned in the non-goal of this proposal. Whatever outcome results from the transaction discussion can apply to both single and batch table load endpoints. On Tue, Feb 3, 2026 at 5:48 PM Guotao Yu <[email protected]> wrote: > Hi Steven, > > 在 2026年2月3日 02:04:13 上，Steven Wu <[email protected]> 写道： > >> Hi, >> >> I would like to discuss a proposal to add batch load endpoints for tables >> and views to the REST spec. >> >> https://docs.google.com/document/d/1VW5hgaaajRWtp5KbOU3s83YyoyPi5WOSvHtoJ_yXzJs/edit?tab=t.0 >> >> It can help with the use cases >> * Catalog federation: improve refresh throughput and reduce load on the >> source catalog >> * Improve planning performance by loading multiple referenced tables in >> one request. >> * Improve MV freshness evaluation if referencing multiple source tables >> >> Thanks, >> Steven >> > > I strongly agree with the role of batch loading interfaces in optimizing > the planning performance of the engine. In specific implementations, > concurrent loading can also be used to improve scenarios involving many > tables in queries. After looking at the batch loading API, I have the > following questions: > > 1. Can the batch loading interface support quick failure? If the engine > hopes to fail immediately upon encountering a single table during the > planning process, there is no need to load subsequent tables. > > 2. Is it necessary to support time travel configuration at the table > level? In time travel queries, the engine may need to load specific > versions of table metadata. > > — > Regards > Guotao Yu >
