"use strict";(self.webpackChunk=self.webpackChunk||[]).push([[6111],{3905:(e,t,n)=>{n.d(t,{Zo:()=>p,kt:()=>h});var a=n(67294);function r(e,t,n){return t in e?Object.defineProperty(e,t,{value:n,enumerable:!0,configurable:!0,writable:!0}):e[t]=n,e}function i(e,t){var n=Object.keys(e);if(Object.getOwnPropertySymbols){var a=Object.getOwnPropertySymbols(e);t&&(a=a.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),n.push.apply(n,a)}return n}function o(e){for(var t=1;t<arguments.length;t++){var n=null!=arguments[t]?arguments[t]:{};t%2?i(Object(n),!0).forEach((function(t){r(e,t,n[t])})):Object.getOwnPropertyDescriptors?Object.defineProperties(e,Object.getOwnPropertyDescriptors(n)):i(Object(n)).forEach((function(t){Object.defineProperty(e,t,Object.getOwnPropertyDescriptor(n,t))}))}return e}function l(e,t){if(null==e)return{};var n,a,r=function(e,t){if(null==e)return{};var n,a,r={},i=Object.keys(e);for(a=0;a<i.length;a++)n=i[a],t.indexOf(n)>=0||(r[n]=e[n]);return r}(e,t);if(Object.getOwnPropertySymbols){var i=Object.getOwnPropertySymbols(e);for(a=0;a<i.length;a++)n=i[a],t.indexOf(n)>=0||Object.prototype.propertyIsEnumerable.call(e,n)&&(r[n]=e[n])}return r}var s=a.createContext({}),u=function(e){var t=a.useContext(s),n=t;return e&&(n="function"==typeof e?e(t):o(o({},t),e)),n},p=function(e){var t=u(e.components);return a.createElement(s.Provider,{value:t},e.children)},c="mdxType",d={inlineCode:"code",wrapper:function(e){var t=e.children;return a.createElement(a.Fragment,{},t)}},m=a.forwardRef((function(e,t){var n=e.components,r=e.mdxType,i=e.originalType,s=e.parentName,p=l(e,["components","mdxType","originalType","parentName"]),c=u(n),m=r,h=c["".concat(s,".").concat(m)]||c[m]||d[m]||i;return n?a.createElement(h,o(o({ref:t},p),{},{components:n})):a.createElement(h,o({ref:t},p))}));function h(e,t){var n=arguments,r=t&&t.mdxType;if("string"==typeof e||r){var i=n.length,o=new Array(i);o[0]=m;var l={};for(var s in t)hasOwnProperty.call(t,s)&&(l[s]=t[s]);l.originalType=e,l[c]="string"==typeof e?e:r,o[1]=l;for(var u=2;u<i;u++)o[u]=n[u];return a.createElement.apply(null,o)}return a.createElement.apply(null,n)}m.displayName="MDXCreateElement"},70579:(e,t,n)=>{n.r(t),n.d(t,{assets:()=>p,contentTitle:()=>s,default:()=>h,frontMatter:()=>l,metadata:()=>u,toc:()=>c});var a=n(87462),r=n(63366),i=(n(67294),n(3905)),o=["components"],l={id:"sql",title:"Druid SQL overview",sidebar_label:"Overview and syntax"},s=void 0,u={unversionedId:"querying/sql",id:"querying/sql",title:"Druid SQL overview",description:"\x3c!--",source:"@site/docs/28.0.0/querying/sql.md",sourceDirName:"querying",slug:"/querying/sql",permalink:"/docs/28.0.0/querying/sql",draft:!1,tags:[],version:"current",frontMatter:{id:"sql",title:"Druid SQL overview",sidebar_label:"Overview and syntax"},sidebar:"docs",previous:{title:"Manual compaction",permalink:"/docs/28.0.0/data-management/manual-compaction"},next:{title:"Tips for writing good queries",permalink:"/docs/28.0.0/querying/tips-good-queries"}},p={},c=[{value:"Syntax",id:"syntax",level:2},{value:"FROM",id:"from",level:2},{value:"UNNEST",id:"unnest",level:2},{value:"WHERE",id:"where",level:2},{value:"GROUP BY",id:"group-by",level:2},{value:"HAVING",id:"having",level:2},{value:"ORDER BY",id:"order-by",level:2},{value:"LIMIT",id:"limit",level:2},{value:"OFFSET",id:"offset",level:2},{value:"UNION ALL",id:"union-all",level:2},{value:"Top-level",id:"top-level",level:3},{value:"Table-level",id:"table-level",level:3},{value:"EXPLAIN PLAN",id:"explain-plan",level:2},{value:"Identifiers and literals",id:"identifiers-and-literals",level:2},{value:"Dynamic parameters",id:"dynamic-parameters",level:2}],d={toc:c},m="wrapper";function h(e){var t=e.components,n=(0,r.Z)(e,o);return(0,i.kt)(m,(0,a.Z)({},d,n,{components:t,mdxType:"MDXLayout"}),(0,i.kt)("admonition",{type:"info"},(0,i.kt)("p",{parentName:"admonition"}," Apache Druid supports two query languages: Druid SQL and ",(0,i.kt)("a",{parentName:"p",href:"/docs/28.0.0/querying/"},"native queries"),".\nThis document describes the SQL language.")),(0,i.kt)("p",null,"You can query data in Druid datasources using Druid SQL. Druid translates SQL queries into its ",(0,i.kt)("a",{parentName:"p",href:"/docs/28.0.0/querying/"},"native query language"),". To learn about translation and how to get the best performance from Druid SQL, see ",(0,i.kt)("a",{parentName:"p",href:"/docs/28.0.0/querying/sql-translation"},"SQL query translation"),"."),(0,i.kt)("p",null,"Druid SQL planning occurs on the Broker.\nSet ",(0,i.kt)("a",{parentName:"p",href:"/docs/28.0.0/configuration/#sql"},"Broker runtime properties")," to configure the query plan and JDBC querying."),(0,i.kt)("p",null,"For information on permissions needed to make SQL queries, see ",(0,i.kt)("a",{parentName:"p",href:"/docs/28.0.0/operations/security-user-auth#sql-permissions"},"Defining SQL permissions"),"."),(0,i.kt)("p",null,"This topic introduces Druid SQL syntax.\nFor more information and SQL querying options see:"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/28.0.0/querying/sql-data-types"},"Data types")," for a list of supported data types for Druid columns."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/28.0.0/querying/sql-aggregations"},"Aggregation functions")," for a list of aggregation functions available for Druid SQL SELECT statements."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/28.0.0/querying/sql-scalar"},"Scalar functions")," for Druid SQL scalar functions including numeric and string functions, IP address functions, Sketch functions, and more."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/28.0.0/querying/sql-multivalue-string-functions"},"SQL multi-value string functions")," for operations you can perform on string dimensions containing multiple values."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/28.0.0/querying/sql-translation"},"Query translation")," for information about how Druid translates SQL queries to native queries before running them.")),(0,i.kt)("p",null,"For information about APIs, see:"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/28.0.0/api-reference/sql-api"},"Druid SQL API")," for information on the HTTP API."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/28.0.0/api-reference/sql-jdbc"},"SQL JDBC driver API")," for information about the JDBC driver API."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/28.0.0/querying/sql-query-context"},"SQL query context")," for information about the query context parameters that affect SQL planning.")),(0,i.kt)("h2",{id:"syntax"},"Syntax"),(0,i.kt)("p",null,"Druid SQL supports SELECT queries with the following structure:"),(0,i.kt)("pre",null,(0,i.kt)("code",{parentName:"pre"},"[ EXPLAIN PLAN FOR ]\n[ WITH tableName [ ( column1, column2, ... ) ] AS ( query ) ]\nSELECT [ ALL | DISTINCT ] { * | exprs }\nFROM { <table> | (<subquery>) | <o1> [ INNER | LEFT ] JOIN <o2> ON condition }\n[ CROSS JOIN UNNEST(source_expression) as table_alias_name(column_alias_name) ]\n[ WHERE expr ]\n[ GROUP BY [ exprs | GROUPING SETS ( (exprs), ... ) | ROLLUP (exprs) | CUBE (exprs) ] ]\n[ HAVING expr ]\n[ ORDER BY expr [ ASC | DESC ], expr [ ASC | DESC ], ... ]\n[ LIMIT limit ]\n[ OFFSET offset ]\n[ UNION ALL <another query> ]\n")),(0,i.kt)("h2",{id:"from"},"FROM"),(0,i.kt)("p",null,"The FROM clause can refer to any of the following:"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/28.0.0/querying/datasource#table"},"Table datasources")," from the ",(0,i.kt)("inlineCode",{parentName:"li"},"druid")," schema. This is the default schema, so Druid table\ndatasources can be referenced as either ",(0,i.kt)("inlineCode",{parentName:"li"},"druid.dataSourceName")," or simply ",(0,i.kt)("inlineCode",{parentName:"li"},"dataSourceName"),"."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/28.0.0/querying/datasource#lookup"},"Lookups")," from the ",(0,i.kt)("inlineCode",{parentName:"li"},"lookup")," schema, for example ",(0,i.kt)("inlineCode",{parentName:"li"},"lookup.countries"),". Note that lookups can\nalso be queried using the ",(0,i.kt)("a",{parentName:"li",href:"/docs/28.0.0/querying/sql-scalar#string-functions"},(0,i.kt)("inlineCode",{parentName:"a"},"LOOKUP")," function"),"."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/28.0.0/querying/datasource#query"},"Subqueries"),"."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/28.0.0/querying/datasource#join"},"Joins")," between anything in this list, except between native datasources (table, lookup,\nquery) and system tables. The join condition must be an equality between expressions from the left- and right-hand side\nof the join."),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("a",{parentName:"li",href:"/docs/28.0.0/querying/sql-metadata-tables"},"Metadata tables")," from the ",(0,i.kt)("inlineCode",{parentName:"li"},"INFORMATION_SCHEMA")," or ",(0,i.kt)("inlineCode",{parentName:"li"},"sys")," schemas. Unlike the other options for the\nFROM clause, metadata tables are not considered datasources. They exist only in the SQL layer.")),(0,i.kt)("p",null,"For more information about table, lookup, query, and join datasources, refer to the ",(0,i.kt)("a",{parentName:"p",href:"/docs/28.0.0/querying/datasource"},"Datasources"),"\ndocumentation."),(0,i.kt)("h2",{id:"unnest"},"UNNEST"),(0,i.kt)("p",null,"The UNNEST clause unnests ARRAY typed values. The source for UNNEST can be an array type column, or an input that's been transformed into an array, such as with helper functions like ",(0,i.kt)("a",{parentName:"p",href:"/docs/28.0.0/querying/sql-multivalue-string-functions"},(0,i.kt)("inlineCode",{parentName:"a"},"MV_TO_ARRAY"))," or ",(0,i.kt)("a",{parentName:"p",href:"/docs/28.0.0/querying/sql-array-functions"},(0,i.kt)("inlineCode",{parentName:"a"},"ARRAY")),"."),(0,i.kt)("p",null,"The following is the general syntax for UNNEST, specifically a query that returns the column that gets unnested:"),(0,i.kt)("pre",null,(0,i.kt)("code",{parentName:"pre",className:"language-sql"},"SELECT column_alias_name FROM datasource CROSS JOIN UNNEST(source_expression1) AS table_alias_name1(column_alias_name1) CROSS JOIN UNNEST(source_expression2) AS table_alias_name2(column_alias_name2) ...\n")),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"The ",(0,i.kt)("inlineCode",{parentName:"li"},"datasource")," for UNNEST can be any Druid datasource, such as the following:",(0,i.kt)("ul",{parentName:"li"},(0,i.kt)("li",{parentName:"ul"},"A table, such as  ",(0,i.kt)("inlineCode",{parentName:"li"},"FROM a_table"),"."),(0,i.kt)("li",{parentName:"ul"},"A subset of a table based on a query, a filter, or a JOIN. For example, ",(0,i.kt)("inlineCode",{parentName:"li"},"FROM (SELECT columnA,columnB,columnC from a_table)"),"."))),(0,i.kt)("li",{parentName:"ul"},"The ",(0,i.kt)("inlineCode",{parentName:"li"},"source_expression")," for the UNNEST function must be an array and can come from any expression. UNNEST works directly on Druid ARRAY typed columns. If the column you are unnesting is a multi-value VARCHAR, you must specify ",(0,i.kt)("inlineCode",{parentName:"li"},"MV_TO_ARRAY(dimension)")," to convert it to an ARRAY type. You can also specify any expression that has an SQL array datatype. For example, you can call UNNEST on the following:",(0,i.kt)("ul",{parentName:"li"},(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("inlineCode",{parentName:"li"},"ARRAY[dim1,dim2]")," if you want to make an array out of two dimensions. "),(0,i.kt)("li",{parentName:"ul"},(0,i.kt)("inlineCode",{parentName:"li"},"ARRAY_CONCAT(dim1,dim2)")," if you want to concatenate two multi-value dimensions. "))),(0,i.kt)("li",{parentName:"ul"},"The ",(0,i.kt)("inlineCode",{parentName:"li"},"AS table_alias_name(column_alias_name)")," clause  is not required but is highly recommended. Use it to specify the output, which can be an existing column or a new one. Replace ",(0,i.kt)("inlineCode",{parentName:"li"},"table_alias_name")," and ",(0,i.kt)("inlineCode",{parentName:"li"},"column_alias_name")," with a table and column name you want to alias the unnested results to. If you don't provide this, Druid uses a nondescriptive name, such as ",(0,i.kt)("inlineCode",{parentName:"li"},"EXPR$0"),".")),(0,i.kt)("p",null,"Keep the following things in mind when writing your query:"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"You can unnest multiple source expressions in a single query."),(0,i.kt)("li",{parentName:"ul"},"Notice the CROSS JOIN between the datasource and the UNNEST function. This is needed in most cases of the UNNEST function. Specifically, it is not needed when you're unnesting an inline array since the array itself is the datasource."),(0,i.kt)("li",{parentName:"ul"},"If you view the native explanation of a SQL UNNEST, you'll notice that Druid uses ",(0,i.kt)("inlineCode",{parentName:"li"},"j0.unnest")," as a virtual column to perform the unnest. An underscore is added for each unnest, so you may notice virtual columns named ",(0,i.kt)("inlineCode",{parentName:"li"},"_j0.unnest")," or ",(0,i.kt)("inlineCode",{parentName:"li"},"__j0.unnest"),"."),(0,i.kt)("li",{parentName:"ul"},"UNNEST preserves the ordering of the source array that is being unnested.")),(0,i.kt)("p",null,"For examples, see the ",(0,i.kt)("a",{parentName:"p",href:"/docs/28.0.0/tutorials/tutorial-unnest-arrays"},"Unnest arrays tutorial"),"."),(0,i.kt)("p",null,"The UNNEST function has the following limitations:"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"The function does not remove any duplicates or nulls in an array. Nulls will be treated as any other value in an array. If there are multiple nulls within the array, a record corresponding to each of the nulls gets created."),(0,i.kt)("li",{parentName:"ul"},"Arrays of complex objects inside complex JSON types are not supported.")),(0,i.kt)("p",null,"UNNEST is the SQL equivalent of the ",(0,i.kt)("a",{parentName:"p",href:"/docs/28.0.0/querying/datasource#unnest"},"unnest datasource"),"."),(0,i.kt)("h2",{id:"where"},"WHERE"),(0,i.kt)("p",null,"The WHERE clause refers to columns in the FROM table, and will be translated to ",(0,i.kt)("a",{parentName:"p",href:"/docs/28.0.0/querying/filters"},"native filters"),". The\nWHERE clause can also reference a subquery, like ",(0,i.kt)("inlineCode",{parentName:"p"},"WHERE col1 IN (SELECT foo FROM ...)"),". Queries like this are executed\nas a join on the subquery, described in the ",(0,i.kt)("a",{parentName:"p",href:"/docs/28.0.0/querying/sql-translation#subqueries"},"Query translation")," section."),(0,i.kt)("p",null,"Strings and numbers can be compared in the WHERE clause of a SQL query through implicit type conversion.\nFor example, you can evaluate ",(0,i.kt)("inlineCode",{parentName:"p"},"WHERE stringDim = 1")," for a string-typed dimension named ",(0,i.kt)("inlineCode",{parentName:"p"},"stringDim"),".\nHowever, for optimal performance, you should explicitly cast the reference number as a string when comparing against a string dimension:"),(0,i.kt)("pre",null,(0,i.kt)("code",{parentName:"pre"},"WHERE stringDim = '1'\n")),(0,i.kt)("p",null,"Similarly, if you compare a string-typed dimension with reference to an array of numbers, cast the numbers to strings:"),(0,i.kt)("pre",null,(0,i.kt)("code",{parentName:"pre"},"WHERE stringDim IN ('1', '2', '3')\n")),(0,i.kt)("p",null,"Note that explicit type casting does not lead to significant performance improvement when comparing strings and numbers involving numeric dimensions since numeric dimensions are not indexed."),(0,i.kt)("h2",{id:"group-by"},"GROUP BY"),(0,i.kt)("p",null,"The GROUP BY clause refers to columns in the FROM table. Using GROUP BY, DISTINCT, or any aggregation functions will\ntrigger an aggregation query using one of Druid's ",(0,i.kt)("a",{parentName:"p",href:"/docs/28.0.0/querying/sql-translation#query-types"},"three native aggregation query types"),". GROUP BY\ncan refer to an expression or a select clause ordinal position (like ",(0,i.kt)("inlineCode",{parentName:"p"},"GROUP BY 2")," to group by the second selected\ncolumn)."),(0,i.kt)("p",null,"The GROUP BY clause can also refer to multiple grouping sets in three ways. The most flexible is GROUP BY GROUPING SETS,\nfor example ",(0,i.kt)("inlineCode",{parentName:"p"},"GROUP BY GROUPING SETS ( (country, city), () )"),". This example is equivalent to a ",(0,i.kt)("inlineCode",{parentName:"p"},"GROUP BY country, city"),"\nfollowed by ",(0,i.kt)("inlineCode",{parentName:"p"},"GROUP BY ()")," (a grand total). With GROUPING SETS, the underlying data is only scanned one time, leading to\nbetter efficiency. Second, GROUP BY ROLLUP computes a grouping set for each level of the grouping expressions. For\nexample ",(0,i.kt)("inlineCode",{parentName:"p"},"GROUP BY ROLLUP (country, city)")," is equivalent to ",(0,i.kt)("inlineCode",{parentName:"p"},"GROUP BY GROUPING SETS ( (country, city), (country), () )"),"\nand will produce grouped rows for each country / city pair, along with subtotals for each country, along with a grand\ntotal. Finally, GROUP BY CUBE computes a grouping set for each combination of grouping expressions. For example,\n",(0,i.kt)("inlineCode",{parentName:"p"},"GROUP BY CUBE (country, city)")," is equivalent to ",(0,i.kt)("inlineCode",{parentName:"p"},"GROUP BY GROUPING SETS ( (country, city), (country), (city), () )"),"."),(0,i.kt)("p",null,"Grouping columns that do not apply to a particular row will contain ",(0,i.kt)("inlineCode",{parentName:"p"},"NULL"),". For example, when computing\n",(0,i.kt)("inlineCode",{parentName:"p"},"GROUP BY GROUPING SETS ( (country, city), () )"),", the grand total row corresponding to ",(0,i.kt)("inlineCode",{parentName:"p"},"()")," will have ",(0,i.kt)("inlineCode",{parentName:"p"},"NULL"),' for the\n"country" and "city" columns. Column may also be ',(0,i.kt)("inlineCode",{parentName:"p"},"NULL")," if it was ",(0,i.kt)("inlineCode",{parentName:"p"},"NULL")," in the data itself. To differentiate such rows,\nyou can use ",(0,i.kt)("inlineCode",{parentName:"p"},"GROUPING")," aggregation. "),(0,i.kt)("p",null,"When using GROUP BY GROUPING SETS, GROUP BY ROLLUP, or GROUP BY CUBE, be aware that results may not be generated in the\norder that you specify your grouping sets in the query. If you need results to be generated in a particular order, use\nthe ORDER BY clause."),(0,i.kt)("h2",{id:"having"},"HAVING"),(0,i.kt)("p",null,"The HAVING clause refers to columns that are present after execution of GROUP BY. It can be used to filter on either\ngrouping expressions or aggregated values. It can only be used together with GROUP BY."),(0,i.kt)("h2",{id:"order-by"},"ORDER BY"),(0,i.kt)("p",null,"The ORDER BY clause refers to columns that are present after execution of GROUP BY. It can be used to order the results\nbased on either grouping expressions or aggregated values. ORDER BY can refer to an expression or a select clause\nordinal position (like ",(0,i.kt)("inlineCode",{parentName:"p"},"ORDER BY 2")," to order by the second selected column). For non-aggregation queries, ORDER BY\ncan only order by the ",(0,i.kt)("inlineCode",{parentName:"p"},"__time")," column. For aggregation queries, ORDER BY can order by any column."),(0,i.kt)("h2",{id:"limit"},"LIMIT"),(0,i.kt)("p",null,"The LIMIT clause limits the number of rows returned. In some situations Druid will push down this limit to data servers,\nwhich boosts performance. Limits are always pushed down for queries that run with the native Scan or TopN query types.\nWith the native GroupBy query type, it is pushed down when ordering on a column that you are grouping by. If you notice\nthat adding a limit doesn't change performance very much, then it's possible that Druid wasn't able to push down the\nlimit for your query."),(0,i.kt)("h2",{id:"offset"},"OFFSET"),(0,i.kt)("p",null,"The OFFSET clause skips a certain number of rows when returning results."),(0,i.kt)("p",null,"If both LIMIT and OFFSET are provided, then OFFSET will be applied first, followed by LIMIT. For example, using\nLIMIT 100 OFFSET 10 will return 100 rows, starting from row number 10."),(0,i.kt)("p",null,"Together, LIMIT and OFFSET can be used to implement pagination. However, note that if the underlying datasource is\nmodified between page fetches, then the different pages will not necessarily align with each other."),(0,i.kt)("p",null,"There are two important factors that can affect the performance of queries that use OFFSET:"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Skipped rows still need to be generated internally and then discarded, meaning that raising offsets to high values\ncan cause queries to use additional resources."),(0,i.kt)("li",{parentName:"ul"},"OFFSET is only supported by the Scan and GroupBy ",(0,i.kt)("a",{parentName:"li",href:"/docs/28.0.0/querying/sql-translation#query-types"},"native query types"),". Therefore, a query with OFFSET\nwill use one of those two types, even if it might otherwise have run as a Timeseries or TopN. Switching query engines\nin this way can affect performance.")),(0,i.kt)("h2",{id:"union-all"},"UNION ALL"),(0,i.kt)("p",null,"The UNION ALL operator fuses multiple queries together. Druid SQL supports the UNION ALL operator in two situations: top-level and table-level, as described below. Queries that use UNION ALL in any other way will fail."),(0,i.kt)("h3",{id:"top-level"},"Top-level"),(0,i.kt)("p",null,"In top-level queries, you can use UNION ALL at the very top outer layer of the query - not in a subquery, and not in the FROM clause. The underlying queries run sequentially. Druid concatenates their results so that they appear one after the other."),(0,i.kt)("p",null,"For example:"),(0,i.kt)("pre",null,(0,i.kt)("code",{parentName:"pre"},"SELECT COUNT(*) FROM tbl WHERE my_column = 'value1'\nUNION ALL\nSELECT COUNT(*) FROM tbl WHERE my_column = 'value2'\n")),(0,i.kt)("p",null,"Certain limitations apply when you use a top-level UNION ALL. For all top-level UNION ALL queries, you can't apply a GROUP BY, ORDER BY, or any other operator to the results of the query. For any top-level UNION ALL that uses the MSQ task engine, the SQL planner attempts to plan the top-level UNION ALL as a table-level UNION ALL. Because of this, UNION ALL queries that use the MSQ task engine always behave the same as table-level UNION ALL queries. They have the same characteristics and limitations. If the planner can't plan the query as a table-level UNION ALL, the query fails."),(0,i.kt)("h3",{id:"table-level"},"Table-level"),(0,i.kt)("p",null,"In table-level queries, you must use UNION ALL in a subquery in the FROM clause, and create the lower-level subqueries that are inputs to the UNION ALL operator as simple table SELECTs. You can't use features like expressions, column aliasing, JOIN, GROUP BY, or ORDER BY in table-level queries."),(0,i.kt)("p",null,"The query runs natively using a ",(0,i.kt)("a",{parentName:"p",href:"/docs/28.0.0/querying/datasource#union"},"union datasource"),"."),(0,i.kt)("p",null,"At table-level queries, you must select the same columns from each table in the same order, and those columns must either have the same types, or types that can be implicitly cast to each other (such as different numeric types). For this reason, it is generally more robust to write your queries to select specific columns. If you use ",(0,i.kt)("inlineCode",{parentName:"p"},"SELECT *"),", you must modify your queries if a new column is added to one table but not to the others."),(0,i.kt)("p",null,"For example:"),(0,i.kt)("pre",null,(0,i.kt)("code",{parentName:"pre"},"SELECT col1, COUNT(*)\nFROM (\n  SELECT col1, col2, col3 FROM tbl1\n  UNION ALL\n  SELECT col1, col2, col3 FROM tbl2\n)\nGROUP BY col1\n")),(0,i.kt)("p",null,"With table-level UNION ALL, the rows from the unioned tables are not guaranteed to process in any particular order. They may process in an interleaved fashion. If you need a particular result ordering, use ",(0,i.kt)("a",{parentName:"p",href:"#order-by"},"ORDER BY")," on the outer query."),(0,i.kt)("h2",{id:"explain-plan"},"EXPLAIN PLAN"),(0,i.kt)("p",null,'Add "EXPLAIN PLAN FOR" to the beginning of any query to get information about how it will be translated. In this case,\nthe query will not actually be executed. Refer to the ',(0,i.kt)("a",{parentName:"p",href:"/docs/28.0.0/querying/sql-translation#interpreting-explain-plan-output"},"Query translation"),"\ndocumentation for more information on the output of EXPLAIN PLAN."),(0,i.kt)("admonition",{type:"info"},(0,i.kt)("p",{parentName:"admonition"}," For the legacy plan, be careful when interpreting EXPLAIN PLAN output, and use ",(0,i.kt)("a",{parentName:"p",href:"/docs/28.0.0/configuration/#request-logging"},"request logging")," if in doubt.\nRequest logs show the exact native query that will be run. Alternatively, to see the native query plan, set ",(0,i.kt)("inlineCode",{parentName:"p"},"useNativeQueryExplain")," to true in the query context.")),(0,i.kt)("h2",{id:"identifiers-and-literals"},"Identifiers and literals"),(0,i.kt)("p",null,"Identifiers like datasource and column names can optionally be quoted using double quotes. To escape a double quote\ninside an identifier, use another double quote, like ",(0,i.kt)("inlineCode",{parentName:"p"},'"My ""very own"" identifier"'),". All identifiers are case-sensitive\nand no implicit case conversions are performed."),(0,i.kt)("p",null,"Literal strings should be quoted with single quotes, like ",(0,i.kt)("inlineCode",{parentName:"p"},"'foo'"),". Literal strings with Unicode escapes can be written\nlike ",(0,i.kt)("inlineCode",{parentName:"p"},"U&'fo\\00F6'"),", where character codes in hex are prefixed by a backslash. Literal numbers can be written in forms\nlike ",(0,i.kt)("inlineCode",{parentName:"p"},"100")," (denoting an integer), ",(0,i.kt)("inlineCode",{parentName:"p"},"100.0")," (denoting a floating point value), or ",(0,i.kt)("inlineCode",{parentName:"p"},"1.0e5")," (scientific notation). Literal\ntimestamps can be written like ",(0,i.kt)("inlineCode",{parentName:"p"},"TIMESTAMP '2000-01-01 00:00:00'"),". Literal intervals, used for time arithmetic, can be\nwritten like ",(0,i.kt)("inlineCode",{parentName:"p"},"INTERVAL '1' HOUR"),", ",(0,i.kt)("inlineCode",{parentName:"p"},"INTERVAL '1 02:03' DAY TO MINUTE"),", ",(0,i.kt)("inlineCode",{parentName:"p"},"INTERVAL '1-2' YEAR TO MONTH"),", and so on."),(0,i.kt)("h2",{id:"dynamic-parameters"},"Dynamic parameters"),(0,i.kt)("p",null,"Druid SQL supports dynamic parameters using question mark (",(0,i.kt)("inlineCode",{parentName:"p"},"?"),") syntax, where parameters are bound to ",(0,i.kt)("inlineCode",{parentName:"p"},"?")," placeholders\nat execution time. To use dynamic parameters, replace any literal in the query with a ",(0,i.kt)("inlineCode",{parentName:"p"},"?")," character and provide a\ncorresponding parameter value when you execute the query. Parameters are bound to the placeholders in the order in\nwhich they are passed. Parameters are supported in both the ",(0,i.kt)("a",{parentName:"p",href:"/docs/28.0.0/api-reference/sql-api"},"HTTP POST")," and ",(0,i.kt)("a",{parentName:"p",href:"/docs/28.0.0/api-reference/sql-jdbc"},"JDBC")," APIs."),(0,i.kt)("p",null,"In certain cases, using dynamic parameters in expressions can cause type inference issues which cause your query to fail, for example:"),(0,i.kt)("pre",null,(0,i.kt)("code",{parentName:"pre",className:"language-sql"},"SELECT * FROM druid.foo WHERE dim1 like CONCAT('%', ?, '%')\n")),(0,i.kt)("p",null,"To solve this issue, explicitly provide the type of the dynamic parameter using the ",(0,i.kt)("inlineCode",{parentName:"p"},"CAST")," keyword. Consider the fix for the preceding example:"),(0,i.kt)("pre",null,(0,i.kt)("code",{parentName:"pre"},"SELECT * FROM druid.foo WHERE dim1 like CONCAT('%', CAST (? AS VARCHAR), '%')\n")))}h.isMDXComponent=!0}}]);