jtuglu1 commented on code in PR #18568:
URL: https://github.com/apache/druid/pull/18568#discussion_r2392453970
##########
processing/src/main/java/org/apache/druid/query/scan/ScanQueryQueryToolChest.java:
##########
@@ -191,6 +198,80 @@ public Sequence<Object[]> resultsAsArrays(final ScanQuery
query, final Sequence<
);
}
+ @Override
+ public CacheStrategy<ScanResultValue, ScanResultValue, ScanQuery>
getCacheStrategy(
+ final ScanQuery query,
+ @Nullable final ObjectMapper objectMapper
+ )
+ {
+ return new CacheStrategy<>()
+ {
+ @Override
+ public boolean isCacheable(ScanQuery query, boolean willMergeRunners,
boolean segmentLevel)
+ {
+ // Currently, there is no bijective mapping from ScanResultValue to
Result<BySegmentResultValueClass<ScanResultValue>>.
+ // This means queries will fail if:
+ // - A query is issued with bySegment:true
+ // - Segment-level cache is enabled on the broker (in which case it
sends bySegment queries to data nodes).
+ return !query.context().isBySegment() && (!segmentLevel ||
willMergeRunners);
+ }
+
+ @Override
+ public byte[] computeCacheKey(ScanQuery query)
+ {
+ CacheKeyBuilder builder = new CacheKeyBuilder(SCAN_QUERY)
+ .appendCacheable(query.getVirtualColumns())
Review Comment:
Yeah, this I had also wondered. Bit of an odd design, but result level cache
will actually
[append](https://github.com/apache/druid/blob/-/processing/src/main/java/org/apache/druid/query/CacheStrategy.java#L88)
datasource/interval already. That also happens
[here](https://github.com/apache/druid/blob/-/server/src/main/java/org/apache/druid/client/CachingClusteredClient.java#L870)
and
[here](https://github.com/apache/druid/blob/-/server/src/main/java/org/apache/druid/client/CachingClusteredClient.java#L850)
for both segment-level and result-level cache.
I personally would've just included these in the cache key so it's easily
testabe.
##########
processing/src/main/java/org/apache/druid/query/scan/ScanQueryQueryToolChest.java:
##########
@@ -191,6 +198,80 @@ public Sequence<Object[]> resultsAsArrays(final ScanQuery
query, final Sequence<
);
}
+ @Override
+ public CacheStrategy<ScanResultValue, ScanResultValue, ScanQuery>
getCacheStrategy(
+ final ScanQuery query,
+ @Nullable final ObjectMapper objectMapper
+ )
+ {
+ return new CacheStrategy<>()
+ {
+ @Override
+ public boolean isCacheable(ScanQuery query, boolean willMergeRunners,
boolean segmentLevel)
+ {
+ // Currently, there is no bijective mapping from ScanResultValue to
Result<BySegmentResultValueClass<ScanResultValue>>.
+ // This means queries will fail if:
+ // - A query is issued with bySegment:true
+ // - Segment-level cache is enabled on the broker (in which case it
sends bySegment queries to data nodes).
+ return !query.context().isBySegment() && (!segmentLevel ||
willMergeRunners);
+ }
+
+ @Override
+ public byte[] computeCacheKey(ScanQuery query)
+ {
+ CacheKeyBuilder builder = new CacheKeyBuilder(SCAN_QUERY)
+ .appendCacheable(query.getVirtualColumns())
Review Comment:
Yeah, this I had also wondered. Bit of an odd design, but result level cache
will actually
[append](https://github.com/apache/druid/blob/-/processing/src/main/java/org/apache/druid/query/CacheStrategy.java#L88)
datasource/interval already. That also happens
[here](https://github.com/apache/druid/blob/-/server/src/main/java/org/apache/druid/client/CachingClusteredClient.java#L870)
and
[here](https://github.com/apache/druid/blob/-/server/src/main/java/org/apache/druid/client/CachingClusteredClient.java#L850)
for both segment-level and result-level cache.
I personally would've just included these in the cache key so it's easily
testable e2e.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
