abhishekagarwal87 commented on code in PR #13173:
URL: https://github.com/apache/druid/pull/13173#discussion_r993436712
##########
benchmarks/src/test/java/org/apache/druid/benchmark/query/SqlBenchmark.java:
##########
@@ -392,7 +392,23 @@
// 20: GroupBy, doubles sketches
"SELECT dimZipf, APPROX_QUANTILE_DS(sumFloatNormal, 0.5),
DS_QUANTILES_SKETCH(maxLongUniform) "
+ "FROM foo "
- + "GROUP BY 1"
+ + "GROUP BY 1",
+
+ //21: Order by with alias with large in filter
+ "SELECT __time as t, dimSequential from foo "
+ + " where (dimSequential in (select DISTINCT dimSequential from foo)) "
+ + " order by 1 limit 1",
+
+ //22: Order by without alias with large in filter
+ "SELECT __time, dimSequential from foo "
+ + " where (dimSequential in (select DISTINCT dimSequential from foo)) "
+ + " order by 1 limit 1",
+
+ //23: Group by and Order by with alias with large in filter nested query
+ "SELECT __time as t, dimSequential from foo "
+ + " where dimSequential in (select dimSequential from foo where "
+ + " dimSequential in (select dimSequential from foo)) "
Review Comment:
A large foo table here does not affect planning time. But if it was instead
a filter with inline data like `dimSequential in ('1', '2', '3' .. '100')` that
we know does increase the planning time.
--
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]
