+1 from me, this makes sense. Avoiding a full loadTable for cases like credential vending is a clear win, and keeping the relevant location properties in the table entity feels like a reasonable incremental step. I believe it also aligns well with the earlier direction of storing selected metadata in persistence without committing to persisting the full TableMetadata yet.
Thanks for driving this and for the PR. Yufei On Tue, Jan 27, 2026 at 9:55 AM Prashant Singh via dev < [email protected]> wrote: > Hello everyone, > > Presently since not all the location properties are stored in the entity > one has to do complete loadTable (i.e read the table from the object > store), even for existing use cases such as credential endpoint i.e > vend the cred of the table. This is super expensive, we can optimize this > if we start keeping these properties of the table in the table entity > (polaris persistence). > > With this we will have a way to do cred vending, in future (to remote sign) > without going to object store. > > Note if we take dependency on this we would have to think of *backfill* but > for step 1 it seems a reasonable step as i personally see this as an > extension of storing yet another set of props like we did [1], while we > still think / debate on if we wanna store the whole table metadata in > persistence, would love to know what other folks think, if anyone have > *objection* to it. > > I proactively have created a pr [2] for the same. > > Huge thanks to Alex for proposing this in their remote signing effort in > the first place. > > [1] https://github.com/apache/polaris/pull/2735 > > [2] https://github.com/apache/polaris/pull/3226 > > [3] https://github.com/apache/polaris/pull/2280#discussion_r2519568503 > > > Best, > > Prashant Singh >
