Seems a nice optimization. I also echo Piotr's point about the list endpoints. Either a `relation` or a `table-like` are good to have. Looking forward to a formal proposal!
Yufei On Thu, Dec 5, 2024 at 5:37 AM Piotr Findeisen <piotr.findei...@gmail.com> wrote: > Hi > > I like the idea to just "get relation" to get the relation in one shot. > Similar thing applies to listing relations. This is obviously less common > operation, but not uncommon and also more expensive. > BI tools query information_schema.tables (and other information_schema > information). > To complete information_schema.tables query we need to call "list tables" > and "list views" separately, whereas it could be sufficient to "list > relations". > > Given than tables views and materialized views all share single namespace, > such a unified API should be possible to add and definitely would be > beneficial for users. > > Best, > Piotr > > > > > On Thu, 5 Dec 2024 at 08:53, Vladimir Ozerov <voze...@querifylabs.com> > wrote: > >> Hi, >> >> Consider the query “SELECT * FROM t”. >> >> The query engine needs to resolve the object “t” during semantic >> analysis. In Iceberg, this could be a table, a view, a materialized view >> (soon). >> >> Currently, the engine has to guess object type via multiple REST calls, >> e.g loadTable -> loadView. This increases latency and REST server load, >> bloats audit records, etc. >> >> Caching may help to some extent, but is not a general solution: doesn’t >> work for one-shot executions (Spark), breaks security and audit, >> inefficient in the case of near real-time ingestion, etc. >> >> Do you think it is worth adding an endpoint, which will return an object >> metadata in one hop? Like “loadObject: oneof(Table, View)”. A careful >> analysis may reveal more use cases potentially prompting even more generic >> endpoint. >> >> If this was discussed earlier, could you kindly point me to the >> discussion (couldn’t find one)? >> >> Regards, >> Vladimir >> >
