LakshSingla commented on code in PR #16800:
URL: https://github.com/apache/druid/pull/16800#discussion_r1751189746
##########
server/src/main/java/org/apache/druid/server/ClientQuerySegmentWalker.java:
##########
@@ -840,6 +846,7 @@ private static <T, QueryType extends Query<T>>
Optional<DataSource> materializeR
+ "from the query context and/or the server
config."
);
} else {
+ resultSequence.set(results);
return Optional.empty();
Review Comment:
> why do we want to fallback - instead of telling the user that this have
failed; and he might want to try the row based limiting?
Copied from one of my responses:
Fallback is mostly for when the types aren't known. At the time this feature
was added, the signature informed by the tool chest didn't need to have a type.
Scan queries only had knowledge of the column names (and not types), group
by/time series... etc. toolchests could return null for the aggregator's
dimensions. The fallback was present for these cases, where it's easy to detect
the failure relatively early in the whole subquery processing flow. Fallback
meant that transitioning from row -> byte based limit was simple. There's an
undocumented parameter that treated these null types as JSON types, but that
had logical flaws of its own iirc.
--
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]
