Hi Prashant It makes sense to me, reducing the "cost" of load table for credential vending. Also, since the property location is quite stable (it basically doesn't change), I don't see any synchronization challenge here.
So +1 for me. To a certain extent, I wonder if we should store all immutable/almost immutable table properties by default, but that's probably a separate discussion :) Regards JB On Tue, Jan 27, 2026 at 5:55 PM 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 >
