Skip to content

Add entitySubType param to BasePersistence.listEntities #2317

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

XN137
Copy link
Contributor

@XN137 XN137 commented Aug 11, 2025

BasePersistence.listEntities has 3 variants:

Page<EntityNameLookupRecord> listEntities(..., PageToken);

Page<EntityNameLookupRecord> listEntities(..., Predicate<PolarisBaseEntity>, PageToken)

<T> Page<T> listEntities(..., Predicate<PolarisBaseEntity>, Function<PolarisBaseEntity, T>, PageToken);

the 1st method exists to only return the subset of entity properties required to build an EntityNameLookupRecord.

the 3rd method supports a predicate and transformer function on the underlying PolarisBaseEntity, which means it has to load all entity properties.

the 2nd method is weird as it supports a full Predicate<PolarisBaseEntity>, which means it has to load all entity properties under the hood for filtering but then throws most of them away to return a EntityNameLookupRecord.
this explains why the implementations of the 2nd method simply forward to the 3rd method usually.
any performance benefits of returning a EntityNameLookupRecord are lost.

as it turns out the 2nd method is only used, because methods 1 and 3 dont support passing a PolarisEntitySubType parameter to filter down the retrieved data.
Note that the sub type property is available from both the PolarisBaseEntity as well as the EntityNameLookupRecord.

By adding this parameter, the 2nd method can go away completely.
we can even push down the sub type filtering into the queries of some of our persistence implementations.
other existing implementations are free to decide whether they want to push it down as well or filter on the query results in memory.

note that since we have no TransactionalPersistence implementation in the codebase that provides an optimized variant of method 1 we can have a default method in the interface that forwards to method 3.

@XN137 XN137 force-pushed the add-PolarisEntitySubType-param-to-BasePersistence.listEntities branch from 6e415e6 to 71dd71c Compare August 11, 2025 13:23
@XN137 XN137 marked this pull request as ready for review August 11, 2025 15:46
// return list of active entities
Page<EntityNameLookupRecord> resultPage =
ms.listEntitiesInCurrentTxn(
callCtx,
resolver.getCatalogIdOrNull(),
resolver.getParentId(),
entityType,
filter,
entitySubType,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note that due to this change calls to PolarisMetaStoreManager.listEntities like here:

private Page<TableIdentifier> listTableLike(
PolarisEntitySubType subType, Namespace namespace, PageToken pageToken) {
PolarisResolvedPathWrapper resolvedEntities = resolvedEntityView.getResolvedPath(namespace);
if (resolvedEntities == null) {
// Illegal state because the namespace should've already been in the static resolution set.
throw new IllegalStateException(
String.format("Failed to fetch resolved namespace '%s'", namespace));
}
List<PolarisEntity> catalogPath = resolvedEntities.getRawFullPath();
ListEntitiesResult listResult =
getMetaStoreManager()
.listEntities(
getCurrentPolarisContext(),
PolarisEntity.toCoreList(catalogPath),
PolarisEntityType.TABLE_LIKE,
subType,
pageToken);

no longer have to load the full PolarisBaseEntity to apply the Predicate<PolarisBaseEntity> and thus they can actually take advantage of optimized implementations of Page<EntityNameLookupRecord> listEntities in BasePersistence that load only the required properties.

Copy link
Contributor

@adutra adutra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome improvement!

@github-project-automation github-project-automation bot moved this from PRs In Progress to Ready to merge in Basic Kanban Board Aug 12, 2025
Copy link
Contributor

@dennishuo dennishuo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

I also would like to adjust the transformer/filter version of listEntities to better reflect it as less of an overloaded method and more of a totally distinct method, but perhaps that fits in better in your other PR #2290

@Nonnull PageToken pageToken) {
// TODO: only fetch the properties required for creating an EntityNameLookupRecord
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To help us remember as well, can we add and update the underlying CONSTRAINT clause to make the implicit index INCLUDE the subTypeCode to this TODO?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'll take a stab at this as an immediate follow-up or file it as a separate issue where i will take note of this additional "index coverage" requirement

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

filed the ticket: #2352

@eric-maynard eric-maynard merged commit ee04df4 into apache:main Aug 13, 2025
12 checks passed
@github-project-automation github-project-automation bot moved this from Ready to merge to Done in Basic Kanban Board Aug 13, 2025
@XN137 XN137 deleted the add-PolarisEntitySubType-param-to-BasePersistence.listEntities branch August 14, 2025 14:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants