+1! I still think we should store the whole TableMetadata or carve out a path forward for it, but this feels directionally correct to me.
On Mon, Feb 2, 2026 at 4:31 PM Yufei Gu <[email protected]> wrote: > +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 > > >
