I am seeing a strange query perf issue: the follow...
# troubleshooting
a
I am seeing a strange query perf issue: the following query should be blazingly fast - instead it is taking 10seconds +: select distinct($segmentName) from <table_name> where ts > 1659083681436 AND ts < 1659093681436 limit 200 Given that broker already has segment pruning logic based on ts, I am not sure and ts column has a range index (no dictionary), I am confused why this query is so slow.
k
please share the response metadata
a
“numServersQueried”: 2, “numServersResponded”: 2, “numSegmentsQueried”: 177, “numSegmentsProcessed”: 175, “numSegmentsMatched”: 172, “numConsumingSegmentsQueried”: 2, “numDocsScanned”: 1357938528, “numEntriesScannedInFilter”: 1452135948, “numEntriesScannedPostFilter”: 1357938528, “numGroupsLimitReached”: false, “totalDocs”: 1458245948, “timeUsedMs”: 10748, “offlineThreadCpuTimeNs”: 0, “realtimeThreadCpuTimeNs”: 0, “offlineSystemActivitiesCpuTimeNs”: 0, “realtimeSystemActivitiesCpuTimeNs”: 0, “offlineResponseSerializationCpuTimeNs”: 0, “realtimeResponseSerializationCpuTimeNs”: 0, “offlineTotalCpuTimeNs”: 0, “realtimeTotalCpuTimeNs”: 0, “segmentStatistics”: [], “traceInfo”: {}, “minConsumingFreshnessTimeMs”: 1659209145425, “numRowsResultSet”: 172
“rows”: [ [ “BROKER_REDUCE(limit:200)“, 0, -1 ], [ “COMBINE_DISTINCT”, 1, 0 ], [ “DISTINCT(keyColumns:$segmentName)“, 2, 1 ], [ “TRANSFORM_PASSTHROUGH($segmentName)“, 3, 2 ], [ “PROJECT($segmentName)“, 4, 3 ], [ “FILTER_FULL_SCAN(operatorRANGE,predicate(ts > ‘1659083681436’ AND ts < ‘1659093681436’))“, 5, 4 ] ]
k
“numDocsScanned”: 1357938528, “numEntriesScannedInFilter”: 1452135948, “numEntriesScannedPostFilter”: 1357938528, “numGroupsLimitReached”: false, “totalDocs”: 1458245948,
its matching the entire data
a
Yes, I understand that but with group by or distinct executor and $segmentName virtualcolumn having a single value per segment, it shouldn’t need to iterator over all the docs. No?
k
yeah, we have some of that optimization actual columns but looks like its not triggered for virtual columns..
a
I tried the same query with physical column, same issue. It is showing FILTER_FULL_SCAN even with range index on ts.
k
what version of Pinot are you using
a
0.10.0
the physical column I am using has dictionary, sorted fwd index. So, not sure why it is not using SortedIndexBasedFilterOperator and but numDocsScannedInFilter is same as totalDocs.
k
yeah, it does not make sense..
can you please file a github issue
a
ok, will do