Operatorcolumn describes the operator that Pinot will run; while as, the
Parent_Idcolumns show the parent-child relationship between operators. This parent-child relationship shows the order in which operators execute. For example,
FILTER_MATCH_ENTIRE_SEGMENTwill execute before and pass its output to
PROJECTwill execute before and pass its output to
TRANSFORM_PASSTHROUGHoperator and so on. Although the EXPLAIN PLAN query produces tabular output, in this document, we show a tree representation of the EXPLAIN PLAN output so that parent-child relationship between operators are easy to see.
FILTER_MATCH_ENTIRE_SEGMENToperator shows that all 977889 records of the segment matched the query. The
PROJECToperator over the filter operator pulls only those columns that were referenced in the query. The
TRANSFORM_PASSTHROUGHoperator just passes the column data from
PROJECToperator to the
SELECT, the query has been successfully evaluated against one segment. Results from different data segments are then combined (
COMBINE_SELECT) and sent to the Broker. The Broker combines and reduces the results from different servers (
BROKER_REDUCE) into a final result that is sent to the user.
FILTER_INVERTED_INDEX). The result was then fully scanned (
FILTER_FULL_SCAN) to evaluate the second predicate "playerName = 'David Allan'". Note that the two predicates are being combined using
ANDin the query; hence, only the data that satsified the first predicate needs to be scanned for evaluating the second predicate. However, if the predicates were being combined using
OR, the query would run very slowly because the entire "playerName" column would need to be scanned from top to bottom to look for values satisfying the second predicate. To improve query efficiency in such cases, one should consider indexing the "playerName" column as well.
AGGREGATE_GROUPBY_ORDERBY) for each segment on the server. The server then combines segment-level GROUP BY results (
COMBINE_GROUPBY_ORDERBY) and sends the combined result to the Broker. The Broker combines GROUP BY result from all the servers to produce the final result which is send to the user. Note that the
COMBINE_SELECToperator from the previous query was not used here, instead a different
COMBINE_GROUPBY_ORDERBYoperator was used. Depending upon the type of query different combine operators such as
COMBINE_ORDERBYetc may be seen.
BROKER_REDUCEindicates that Broker is processing and combining server results into final result that is sent back to the user.
BROKER_REDUCEhas a COMBINE operator as it's child. Combine operator combines the results of query evaluation from each segment on the server and sends the combined result to the Broker. There are several combine operators (
COMBINE_AGGREGATE, etc.) that run depending upon the operations being performned by the query. Under the Combine operator, either a Select (
SELECT_ORDERBY, etc.) or an Aggregate (
AGGREGATE_GROUPBY_ORDERBY, etc.) can appear. Aggreate operator is present when query performs aggregation (
max, etc.); otherwise, a Select operator is present. If the query performs scalar transformations (Addition, Multiplication, Concat, etc.), then one would see TRANSFORM operator appear under the SELECT operator. Often a
TRANSFORM_PASSTHROUGHoperator is present instead of the TRANSFORM operator.
TRANSFORM_PASSTHROUGHjust passes results from operators that appear lower in the operator execution heirarchy to the SELECT operator. FILTER operators usually appear at the bottom of the operator heirarchy and show index use. For example, the presence of FILTER_FULL_SCAN indicates that index was not used (and hence the query is likely to run relatively slow). However, if the query used an index one of the indexed filter operators (
FILTER_JSON_INDEX, etc.) will show up.