PDGGK opened a new pull request, #9266:
URL: https://github.com/apache/paimon/pull/9266
### Purpose
`AbstractFileStoreTable` carries four caches installed by the catalog.
`copy(TableSchema)` re-installs three of them onto the new instance and
silently drops the fourth:
```java
if (snapshotCache != null) { copied.setSnapshotCache(snapshotCache); }
if (manifestCache != null) { copied.setManifestCache(manifestCache); }
if (statsCache != null) { copied.setStatsCache(statsCache); }
return copied; // dvmetaCache is not
carried over
```
The four are declared side by side at `:98-101`, and
`CachingCatalog.loadTable` installs `dvMetaCache` alongside the others at
`:303`. `cache.deletion-vectors.max-num` defaults to **100_000**
(`CatalogOptions:155-159`), so the cache exists by default rather than only
when opted in.
### Why this is the normal path, not an edge case
Every copy funnels through this method — `copy(Map)` → `copyInternal` →
`copy(TableSchema)`, and `copyWithoutTimeTravel` / `copyWithLatestSchema`
likewise. And engines read through a copy: `FileStoreTableFactory:225` ends with
```java
return table.copy(dynamicOptions.toMap());
```
So on a catalog-backed read with any dynamic option, the table that actually
serves the scan has `dvmetaCache == null`, while `snapshotCache`,
`manifestCache` and `statsCache` survive.
### What the user sees
`AbstractFileStoreTable.newSnapshotReader():285` hands `dvmetaCache` to
`SnapshotReaderImpl`, which branches on it at `:661`. With null it degrades
gracefully — no failure — but the index manifest and the deletion-vector index
metadata are re-read from storage on **every** scan plan, and nothing is ever
populated for the next one. The `dvMetaHitCache` / `dvMetaMissedCache` scan
metrics stay at zero, which is what makes it easy to miss: the cache is not
slow, it is simply never consulted.
So a cache that is on by default does nothing on the main read path. On
object storage that is an extra metadata round trip per plan, for the life of
the job.
### What changes
Three lines, in the same shape as the three neighbours immediately above:
```java
if (dvmetaCache != null) {
copied.setDVMetaCache(dvmetaCache);
}
```
### Blast radius
Purely additive. A table with no DV cache installed — the whole
non-caching-catalog path, and any catalog with `cache.deletion-vectors.max-num
= 0` — takes the null branch and is byte-for-byte unchanged.
`org.apache.paimon.table.*Test` is 646 tests, 0 failures.
### Test
`CopyKeepsCachesTest` installs a `DVMetaCache`, copies the table the way
`FileStoreTableFactory` does (a dynamic option), and asserts the copy holds the
same instance. Removing the three lines fails it:
```
Expecting actual:
null
and:
org.apache.paimon.utils.DVMetaCache@4a1c0752
to refer to the same object
```
There was no existing test asserting that any of the four caches survives a
copy, which is presumably how the omission went unnoticed; this one is written
so that adding a fifth cache and forgetting it would be caught the same way.
### API and Format
No change to any option, on-disk format or public signature.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
