WIP: Proposed API to determine freshness of a cached table#3061
WIP: Proposed API to determine freshness of a cached table#3061anjalinorwood wants to merge 1 commit intotrinodb:masterfrom
Conversation
Cached table could take the form of query result cache or a materialized view.
| * Engine does not interpret the token in any way. It simply presents it back to the connector to determine freshness of the cached table | ||
| * the token is associated with. | ||
| */ | ||
| default Optional<TableToken> getTableToken(ConnectorSession session, ConnectorTableHandle tableHandle, TupleDomain<ColumnHandle> predicate) |
There was a problem hiding this comment.
The predicate should be unnecessary. The table handle should encompass all the pushed down predicates, projections or other more complex operations via the applyXXX calls.
There was a problem hiding this comment.
You are right. The 'predicate' parameter is not necessary.
| */ | ||
| package io.prestosql.spi.connector; | ||
|
|
||
| public interface TableToken |
There was a problem hiding this comment.
Does this need to be long term, stable, serializable?
There was a problem hiding this comment.
The idea is that the connector provides the token for each base table when the matview is refreshed. This token needs to be stored somewhere (mat view properties or in the snapshot of storage table if it is an iceberg table). So, you are right this token needs to be serializable.
Since the engine does not interpret the token and simply hands back to the connector to check if view is current, I think the versioning of the token can be managed by the connector. Is this what you meant by 'long term, stable'?
|
This API is being folded into: #3283 |
3 participants
Cached table could take the form of query result cache or a materialized view.