QuestDB attempts to implement standard ANSI SQL. We also attempt to be PostgresSQL compatible, although some of it is work in progress. QuestDB implements the following clauses in this execution order:
- LATEST BY
- GROUP BY (implicit)
- HAVING (implicit)
- ORDER BY
We also implemented sub-queries. They can be used anywhere table name is used. Our sub-query implementation adds virtually zero execution cost to SQL. We encourage their use to add flavours of functional language to old-school SQL.
Important differences from standard SQL
SELECT * FROM Optionality
select * from is optional.
SELECT * FROM tab;
achieves the same effect.
select * from makes SQL look more complete on a single time, there are examples where its optionality makes things a lot easier to read. See examples in
GROUP BY section.
GROUP BY ... HAVING
We do not support explicit
GROUP BY clause. Instead QuestDB optimiser derives group-by implementation from
SELECT clause. For example:
SELECT a, b, c, d, sum(e) FROM tab GROUP BY a, b, c, d;
We find enumerating subset of
SELECT columns in
GROUP BY clause redundant and therefore unnecessary. The same SQL in QuestDB SQL-dialect will look like:
SELECT a, b, c, d, sum(e) FROM tab;
Lets see how we replace
SELECT a, b, c, d, sum(e) FROM tab GROUP BY a, b, c, d HAVING sum(e) > 100;
select * from optionality and featherweight sub-queries come to the rescue:
(SELECT a, b, c, d, sum(e) s FROM tab) WHERE s > 100;
Here we avoided repetitive aggregation expressions without extra furniture syntax.
We have extended SQL language to support our data storage model and simplify semantics of time series queries.
LATEST BY(find out more here)
Please follow the links for detailed description of these clauses.