Feng Guo created CALCITE-5730: --------------------------------- Summary: First nulls are dropped by calcite EnumerableSortLimit Node Key: CALCITE-5730 URL: https://issues.apache.org/jira/browse/CALCITE-5730 Project: Calcite Issue Type: Bug Components: linq4j Reporter: Feng Guo
*Description* The EnumerableSortLimit Node deals with offset with following logic: {code:java} // skip the first 'offset' rows by deleting them from the map if (offset > 0) { // search the key up to (but excluding) which we have to remove entries from the map int skipped = 0; TKey until = null; for (Map.Entry<TKey, List<TSource>> e : map.entrySet()) { skipped += e.getValue().size(); if (skipped > offset) { // we might need to remove entries from the list List<TSource> l = e.getValue(); int toKeep = skipped - offset; if (toKeep < l.size()) { l.subList(0, l.size() - toKeep).clear(); } until = e.getKey(); break; } } if (until == null) { // the offset is bigger than the number of rows in the map return Linq4j.emptyEnumerator(); } map.headMap(until, false).clear(); } {code} In a NULLS FIRST sort, if we set offset=1, limit = 1 when first 10 rows have null compare key, the until will be null. But that does not mean offset bigger than number of rows, it should have results instead of emptyEnumerator; -- This message was sent by Atlassian Jira (v8.20.10#820010)