EXPLAIN

See how KDB will read the tables for a query, without running it; with ANALYZE, run it and see what really happened.

• Category: Querying
• Keywords: EXPLAIN, plan, query plan, EXPLAIN ANALYZE, ANALYZE, actual rows, Execution Time, Planning Time, EXPLAIN (FORMAT JSON), FORMAT JSON, BUFFERS, VERBOSE, EXPLAIN WITH, EXPLAIN DELETE, EXPLAIN UPDATE, EXPLAIN INSERT, EXPLAIN CALL, depends on runtime value, explain plan, slow query, partitions skipped, key range, full scan, hash join, nested loop, filter while scanning, filter after joins, read only key range(s), use index, no index, a scan is cheaper, skipped by column stats, zone maps, KDB_NO_ZONE_MAPS, answer from saved stats, answer from the partition list, KDB_NO_PARTITION_ANSWERS, stored column(s) per row, KDB_NO_COLUMN_MASK, engine: column, engine: row, column engine, row engine, speed
• See also: SELECT (from), Joins (join), SAMPLE BY (sample-by), LATEST ON (latest-on), Partitions, SORT BY and DEDUP KEY (partition-by), Indexes, UNION and subqueries (from-subquery), Transactions, pg_stat_activity and pg_stat_statements (pg-stat-statements)

EXPLAIN shows the plan of a query: which tables KDB reads, how many partitions it skips, how it joins, groups and sorts. It does not run the query and does not show rows. EXPLAIN ANALYZE runs it and adds the real rows and times.

Use it when a query is slow. The most important lines are:

• scan table ... (1 of 2 partitions ...): the time filter lets KDB skip whole partition files. "2 of 2" on a big table means every file is read. The about N rows in that line is an estimate of the whole table's size, not what the query reads.
• ..., 3 skipped by column stats) inside that bracket: a condition like rate > 900 ruled those partitions out from the smallest and biggest value each one holds (see zone maps).
• read only N key range(s) of each partition: KDB jumps straight to the rows of the symbols you asked for.
• answer from saved stats ... or answer from the partition list ...: KDB answers without reading the rows at all (see answers without reading rows).

Example: One symbol, one month: KDB reads 1 of 2 partitions, and only CITY's rows (sample data: sample)

EXPLAIN SELECT time, close FROM ochl_day WHERE symbol = 'CITY' AND time IN '2026-09';

Result:

(5 rows)

EXPLAIN

Syntax:

EXPLAIN SELECT ...
EXPLAIN WITH name AS (SELECT ...) SELECT ...

Shows the plan of a SELECT, one line per step, in a result with one column called plan.

• Returns: rows of text, one step per row (see the plan lines).
• Notes:
  • The main query does not run. But KDB checks it first: an unknown table or column gives the same error as the query itself.
  • A subquery in FROM, a view, and IN (SELECT ...) / (SELECT ...) values are run, because the plan needs their results. EXPLAIN of a query on a slow view is slow too.
  • INSERT, UPDATE, DELETE and CALL can be explained too: see EXPLAIN INSERT, UPDATE, DELETE and EXPLAIN CALL. EXPLAIN SELECT ... FOR UPDATE is an error.
  • EXPLAIN SELECT without FROM gives an empty plan.
  • With UNION ALL, only the first part is described, plus a line union all with N more part(s).
  • In the command line table format long lines are cut. Use kdb sql ... --format csv to see the whole plan.
  • A user with the read role can run EXPLAIN.

Example: Candles: filter, sample, group, sort and limit (sample data: sample)

EXPLAIN SELECT time, symbol, first(open) AS open, max(high) AS high, min(low) AS low, last(close) AS close
FROM ochl_minutes
WHERE time IN '2026-09-10'
SAMPLE BY 15m
ORDER BY symbol, time
LIMIT 10 OFFSET 5;

Result:

(8 rows)

Example: Trade log with the buyer and seller names (sample data: sample)

EXPLAIN SELECT f.transaction_id, b.name AS buyer, s.name AS seller, f.amount
FROM trade_log f
JOIN brokers b ON f.buyer = b.id
LEFT JOIN brokers s ON f.seller = s.id
WHERE f.date IN '2026-09-10' AND b.name LIKE 'N%'
ORDER BY f.amount DESC
LIMIT 5;

Result:

(8 rows)

Example: Latest live price of each symbol (sample data: sample)

EXPLAIN SELECT symbol, ltp, pct_change FROM live_data LATEST ON timestamp PARTITION BY symbol;

Result:

(4 rows)

Example: A subquery in FROM is run first: the plan shows its row count (sample data: sample)

EXPLAIN SELECT t.symbol, t.trades
FROM (SELECT symbol, count(*) AS trades FROM trade_log GROUP BY symbol) t
WHERE t.trades > 5;

Result:

(4 rows)

Example: The query is checked: unknown columns are errors (sample data: sample; shows an error)

EXPLAIN SELECT time, clsoe FROM ochl_day;

Result:

Error: line 1, column 22: unknown column 'clsoe' (table 'ochl_day' has: time symbol open high low close volume)

Example: Schema statements have no plan (sample data: sample; shows an error)

EXPLAIN DROP TABLE trade_log;

Result:

Error: line 1, column 9: expected SELECT, WITH, INSERT, UPDATE, DELETE or CALL after EXPLAIN but found 'DROP'

EXPLAIN ANALYZE

Syntax:

EXPLAIN ANALYZE [VERBOSE] SELECT ...        (ANALYSE works too, as in PostgreSQL)
EXPLAIN (ANALYZE [true | false] [, FORMAT TEXT | JSON] [, VERBOSE] [, BUFFERS] [, COSTS] [, TIMING] [, SUMMARY] [, SETTINGS] [, WAL]) SELECT ...

Runs the query, then shows its plan and what really happened: the rows and the time of every part of the query, which engine read each table, the partitions read and skipped, and the memory it held.

• Returns: the plan lines of EXPLAIN, then:

• Notes:
  • The query really runs, with its time limit and memory limits, and can be cancelled. Its rows are not sent.
  • Only a SELECT that changes nothing is run. EXPLAIN ANALYZE of INSERT, UPDATE, DELETE or CALL, of SELECT ... FOR UPDATE, and of WITH x AS (DELETE ...) SELECT ... is refused, and nothing is changed: use EXPLAIN without ANALYZE for their plan. (PostgreSQL would run them and change the data.)
  • VERBOSE, BUFFERS, COSTS, SUMMARY and SETTINGS are accepted; KDB has no costs or buffer counts to add. TIMING and WAL need ANALYZE, as in PostgreSQL. FORMAT XML and YAML are not supported.
  • Times are wall-clock milliseconds of this run; run it twice to see the effect of files already in memory.

Example: Where the time of a candle report goes: the column engine, 1 of 2 partitions (sample data: sample)

EXPLAIN ANALYZE SELECT symbol, max(high) AS high, min(low) AS low FROM ochl_day WHERE time IN '2026-09' GROUP BY symbol ORDER BY symbol;

Result:

(13 rows)

Example: A join runs on the row engine; its subquery is a part of its own (sample data: sample)

EXPLAIN ANALYZE SELECT b.name, t.trades
FROM (SELECT buyer, count(*) AS trades FROM trade_log GROUP BY buyer) t
JOIN brokers b ON t.buyer = b.id
ORDER BY t.trades DESC LIMIT 3;

Result:

(14 rows)

Example: A change is not run (sample data: sample; shows an error)

EXPLAIN ANALYZE DELETE FROM trade_log;

Result:

Error: EXPLAIN ANALYZE runs the statement to measure it, and KDB does that for SELECT only: an INSERT, UPDATE, DELETE or CALL would really change data. Use EXPLAIN without ANALYZE for its plan

EXPLAIN (FORMAT JSON)

Syntax:

EXPLAIN (FORMAT JSON) SELECT | INSERT | UPDATE | DELETE | CALL ...
EXPLAIN (ANALYZE, FORMAT JSON) SELECT ...

The plan as one JSON value, for tools: one row in the column plan.

• Returns: [{"Plan": {"Node Type": "Query", "Plan Lines": [...]}}]. With ANALYZE the plan also has "Actual Rows", "Actual Total Time" and "Plans": one object per part of the query that ran, with "Relation Name", "Depth", "Engine", "Actual Rows", "Actual Total Time", "Steps" ([{"Step": ..., "Time": ...}]) and, for a table, "Partitions Total", "Partitions Read", "Partitions Skipped", "Partitions Skipped By Column Stats". Next to "Plan" come "Partitions Read", "Peak Memory Bytes", "Planning Time" and "Execution Time".
• Notes: the shape is PostgreSQL's (an array with one object holding "Plan"), but KDB's plan is a list of steps, not a tree of costed nodes: its lines are in "Plan Lines". Times are milliseconds.

Example: The plan of a report, for a tool (sample data: sample)

EXPLAIN (FORMAT JSON) SELECT symbol, last(close) AS close FROM ochl_day GROUP BY symbol;

Result:

(1 row)

Example: What really happened, as JSON (sample data: sample)

EXPLAIN (ANALYZE, FORMAT JSON) SELECT count(*) AS trades FROM trade_log WHERE date IN '2026-09-10';

Result:

(1 row)

EXPLAIN INSERT, UPDATE, DELETE

Syntax:

EXPLAIN DELETE FROM table [WHERE ...]
EXPLAIN UPDATE table SET ... [WHERE ...]
EXPLAIN INSERT INTO table [(columns)] SELECT ...
EXPLAIN INSERT INTO table [(columns)] VALUES (...), ...

Shows how the statement finds its rows: partitions, key ranges, index. No row is changed.

• Returns: rows of text in the column plan.
• Notes:
  • DELETE and UPDATE start with delete from table t (k of n partitions, about r rows) or update table t (...). Then come the same lines as for a SELECT scan: use index ... or read only k key range(s) ..., and filter while scanning: k condition(s). UPDATE ends with set k column(s).
  • INSERT ... SELECT shows insert into table t the rows of this query: and the plan of the SELECT under it, moved in by two spaces.
  • INSERT ... VALUES shows only how many rows it has.
  • Other lines: run the WITH queries first, find the rows with the column engine and take them from its scan (a big keyed table, a condition without an index that the column engine checks; KDB_NO_VECTOR_MATCHES=1 gives the older find the rows with the column engine, then read only them by their keys), look up the key of every row for a clash (ON CONFLICT, INSERT OR REPLACE), find the target rows by t.id IN (1, 2), then match them with the rows of USING (or FROM; match every row with the rows of USING when no part of the WHERE finds them first), return k item(s) per row (RETURNING).
  • An UPDATE or DELETE uses an index whenever one fits: it has no no index: ... choice. Partitions ruled out by column stats are left out of k of n, but the plan does not say how many.
  • The same rights are needed as for the statement itself: EXPLAIN DELETE needs DELETE on the table.
  • With UPDATE ... FROM or DELETE ... USING, conditions that use the other table are counted as filter after matching.

Example: Delete one day of one symbol: 1 partition, 1 key range (sample data: sample)

EXPLAIN DELETE FROM ochl_day WHERE symbol = 'CITY' AND time IN '2026-09-10';
SELECT count(*) AS rows_still_there FROM ochl_day WHERE symbol = 'CITY' AND time IN '2026-09-10';

Result:

EXPLAIN DELETE FROM ochl_day WHERE symbol = 'CITY' AND time IN '2026-09-10'

(3 rows)

SELECT count(*) AS rows_still_there FROM ochl_day WHERE symbol = 'CITY' AND time IN '2026-09-10'

(1 row)

Example: An update of the trades of one day (sample data: sample)

EXPLAIN UPDATE trade_log SET rate = rate * 1.01 WHERE date IN '2026-09-10' AND symbol = 'CITY';

Result:

(4 rows)

Example: Copy CITY's closes of September into another table (sample data: sample)

Setup:

CREATE TABLE city_closes (time TIMESTAMP, close DOUBLE) TIMESERIES(time) PARTITION BY MONTH;

EXPLAIN INSERT INTO city_closes SELECT time, close FROM ochl_day WHERE symbol = 'CITY' AND time IN '2026-09';

Result:

(6 rows)

EXPLAIN CALL

Syntax:

EXPLAIN CALL procedure(argument, ...)

Shows the plan of every statement in the procedure, with the arguments you give. Nothing runs and nothing is changed.

• Returns: rows of text in the column plan: first procedure name(param = value, ...), then step N: <statement> for each statement, with its plan moved in under it.
• Notes:
  • A variable whose value needs no table (DECLARE k LONG DEFAULT 5, SET d2 = dateadd('d', -1, d)) is worked out, and its value is shown (k = 5).
  • A variable that needs a query (DEFAULT (SELECT ...)), a FETCH or a loop gets depends on runtime value. So does every statement that uses it.
  • An IF whose condition is known shows true or false, and only the branch that would run. Otherwise it shows depends on runtime value and every branch.
  • WHILE and FOR bodies are shown once, as every pass or every row.
  • A CALL of another procedure is not opened: explain that one on its own.
  • WITH DEBUG cannot be added: use CALL ... WITH DEBUG to run the procedure and see what each step did.

Example: The plan of a procedure that clears one day of one symbol (sample data: sample)

Setup:

CREATE PROCEDURE clear_day(d TIMESTAMP, sym SYMBOL) AS BEGIN
  DECLARE left_rows LONG DEFAULT (SELECT count(*) FROM ochl_day WHERE symbol = sym);
  DECLARE d_end TIMESTAMP DEFAULT dateadd('d', 1, d);
  DELETE FROM ochl_day WHERE symbol = sym AND time >= d AND time < d_end;
  IF left_rows > 100 THEN
    PRINT 'many rows';
  END IF;
END;

EXPLAIN CALL clear_day('2026-09-10T00:00:00Z', 'CITY');

Result:

(11 rows)

Example: EXPLAIN CALL does not take WITH DEBUG (sample data: sample; shows an error)

Setup:

CREATE PROCEDURE clear_day(d TIMESTAMP, sym SYMBOL) AS BEGIN
  DELETE FROM ochl_day WHERE symbol = sym AND time >= d;
END;

EXPLAIN CALL clear_day('2026-09-10T00:00:00Z', 'CITY') WITH DEBUG;

Result:

Error: line 1, column 9: EXPLAIN CALL does not run the procedure, so WITH DEBUG has nothing to show; use CALL ... WITH DEBUG

The plan lines

Syntax:

aggregates pushed into the k UNION ALL parts: each part groups its own table first
window functions over grouped rows: the grouping runs first as a subquery
answer from the partition list of table name (k of n partitions; no other rows read)
scan table name (k of n partitions, about r rows[, s skipped by column stats])
scan result of name (r rows)
push k condition(s) into view | subquery name [after its windows]
push k rank limit(s) into subquery name
time range from the calendar condition(s): col >= 'start' AND < 'end'
use index name (...)
no index: name would read r row(s), a scan is cheaper[; it reads only the storage keys those rows lie between]
no index: the column stats rule out every partition
answer from saved stats of table name: ...
join | left join | asof join | cross join (hash on k key(s) | key lookup on columns | index lookup on column | nested loop) table name (...)
read only k key range(s) of each partition
build k of n stored column(s) per row: columns
filter while scanning: k condition(s)
filter after joins: k condition(s)
latest row per partition on column
sample by SAMPLE BY ...
group by k key(s), m aggregate(s)
k window/series function(s)
distinct
sort by k key(s)
limit n [offset m]
union all with k more part(s)
delete from | update table name (k of n partitions, about r rows)
set k column(s)
insert into table name the rows of this query:

The lines come in this order. A line is missing when the query does not have that step.

• Notes:
  • Only the first table in FROM skips partitions. A time filter on a joined table does not make it read less: its line always shows all partitions. Put the big time-series table first.
  • A function around the column (upper(symbol) = 'CITY') stops the key ranges: the read only ... line disappears.
  • For a DATE time column, KDB also reads the partition of the next day, to be safe.
  • The engine: line uses the same tests the query uses when it runs. Only the data can still change it: a partition whose min / max column holds a NaN is read by the row engine. Which conditions keep a query in the fast column engine: see WHERE: fast conditions.

Example: Good: the symbol is written plainly, so KDB reads 2 key ranges (sample data: sample)

EXPLAIN SELECT time, symbol, close FROM ochl_day WHERE symbol IN ('CITY', 'COAST') AND time >= '2026-09-01';

Result:

(5 rows)

Example: Slow: a function around symbol reads every row of every partition (sample data: sample)

EXPLAIN SELECT time, symbol, close FROM ochl_day WHERE upper(symbol) = 'CITY';

Result:

(4 rows)

Example: Which engine: the same report, fast and slow (sample data: sample)

EXPLAIN SELECT symbol, avg(close) AS avg_close FROM ochl_day WHERE close > 500 GROUP BY symbol;
EXPLAIN SELECT symbol, avg(close) AS avg_close FROM ochl_day WHERE upper(symbol) = 'CITY' GROUP BY symbol;

Result:

EXPLAIN SELECT symbol, avg(close) AS avg_close FROM ochl_day WHERE close > 500 GROUP BY symbol

(5 rows)

EXPLAIN SELECT symbol, avg(close) AS avg_close FROM ochl_day WHERE upper(symbol) = 'CITY' GROUP BY s

(5 rows)

Example: Big table first: the time filter skips partitions (sample data: sample)

EXPLAIN SELECT b.name, sum(f.amount) AS turnover
FROM trade_log f JOIN brokers b ON f.buyer = b.id
WHERE f.date IN '2026-09-10'
GROUP BY b.name ORDER BY turnover DESC LIMIT 3;

Result:

(8 rows)

Example: Big table second: every trade log partition is read (sample data: sample)

EXPLAIN SELECT b.name, sum(f.amount) AS turnover
FROM brokers b JOIN trade_log f ON f.buyer = b.id
WHERE f.date IN '2026-09-10'
GROUP BY b.name ORDER BY turnover DESC LIMIT 3;

Result:

(6 rows)

Example: No a = b condition: a nested loop (sample data: sample)

EXPLAIN SELECT s.symbol, b.name FROM securities s CROSS JOIN brokers b;

Result:

(4 rows)

Example: Live prices with the last minute candle, and a moving average (sample data: sample)

EXPLAIN SELECT l.timestamp, l.symbol, l.ltp, m.close
FROM live_data l
ASOF JOIN ochl_minutes m ON l.symbol = m.symbol;
EXPLAIN SELECT time, close, sma(close, 3) AS sma3 FROM ochl_day WHERE symbol = 'CITY';

Result:

EXPLAIN SELECT l.timestamp, l.symbol, l.ltp, m.close FROM live_data AS l ASOF JOIN ochl_minutes AS m

(4 rows)

EXPLAIN SELECT time, close, sma(close, 3) AS sma3 FROM ochl_day WHERE symbol = 'CITY'

(6 rows)

Example: DISTINCT and UNION ALL (sample data: sample)

EXPLAIN SELECT DISTINCT symbol FROM trade_log;
EXPLAIN SELECT symbol FROM trade_log WHERE buyer = 58 UNION ALL SELECT symbol FROM trade_log WHERE seller = 58;

Result:

EXPLAIN SELECT DISTINCT symbol FROM trade_log

(4 rows)

EXPLAIN SELECT symbol FROM trade_log WHERE buyer = 58 UNION ALL SELECT symbol FROM trade_log WHERE s

(5 rows)

Example: A DATE time column also reads the next day's partition

Setup:

CREATE TABLE daily_nav (day DATE, fund SYMBOL, nav DOUBLE) TIMESERIES(day) PARTITION BY DAY;
INSERT INTO daily_nav VALUES ('2026-09-08', 'GRWF', 10.2), ('2026-09-09', 'GRWF', 10.3), ('2026-09-10', 'GRWF', 10.1);

EXPLAIN SELECT day, nav FROM daily_nav WHERE day = '2026-09-09';

Result:

(4 rows)

Example: Over 10,000 rows: an index that finds a fifth of them is not used (sample data: sample)

Setup:

CREATE TABLE ticks (time TIMESTAMP, symbol SYMBOL, broker INT, price DOUBLE) TIMESERIES(time) PARTITION BY DAY;
INSERT INTO ticks SELECT m.time, m.symbol, b.id, m.close FROM ochl_minutes m CROSS JOIN brokers b CROSS JOIN securities s;
CREATE INDEX ticks_broker ON ticks (broker);

EXPLAIN SELECT time, price FROM ticks WHERE broker = 58;

Result:

(6 rows)

Example: An index on buyer: buyer = 58 uses it, a condition with OR does not (sample data: sample)

Setup:

CREATE INDEX trade_log_buyer ON trade_log (buyer);

EXPLAIN SELECT transaction_id, symbol, quantity FROM trade_log WHERE buyer = 58;
EXPLAIN SELECT transaction_id, symbol, quantity FROM trade_log WHERE buyer = 58 OR seller = 58;

Result:

EXPLAIN SELECT transaction_id, symbol, quantity FROM trade_log WHERE buyer = 58

(5 rows)

EXPLAIN SELECT transaction_id, symbol, quantity FROM trade_log WHERE buyer = 58 OR seller = 58

(4 rows)

Example: A full-text count and a first page: the index answers them alone (sample data: content-news)

Setup:

CREATE FULLTEXT INDEX news_text ON news (title, body);

EXPLAIN SELECT count(*) FROM news WHERE MATCH(title, body, 'bank');
EXPLAIN SELECT id FROM news WHERE MATCH(title, body, 'bank') LIMIT 2;

Result:

EXPLAIN SELECT count(*) FROM news WHERE match(title, body, 'bank')

(7 rows)

EXPLAIN SELECT id FROM news WHERE match(title, body, 'bank') LIMIT 2

(6 rows)

Example: Unnamed subqueries in a UNION ALL: subquery 1, subquery 2 (sample data: sample)

EXPLAIN ANALYZE SELECT symbol FROM (SELECT symbol FROM trade_log WHERE buyer = 58)
UNION ALL SELECT symbol FROM (SELECT symbol FROM trade_log WHERE seller = 58);

Result:

(16 rows)

Zone maps: partitions skipped by column stats

Syntax:

scan table t (k of n partitions, about r rows, s skipped by column stats)

Every partition file keeps the smallest and the biggest value of each column. When a condition cannot be true for any value in that range, KDB skips the whole partition. rate > 900 skips a partition whose biggest rate is 883.

• Columns: whole numbers, FLOAT, DOUBLE, DECIMAL, DATE and TIMESTAMP. SYMBOL columns are skipped in their own way, by the names each partition holds.
• Notes:
  • It works whether the partition is in memory or not. For a partition not in memory, KDB reads only the stats part of its file (a few hundred bytes) once and keeps it, also after the rows are pushed out of memory. A file written again (after UPDATE, DELETE or new rows) has its stats read again.
  • Rows written since the last checkpoint are checked one by one (up to 4,096 per partition). More than that and the partition is read.
  • It works for SELECT, UPDATE and DELETE, in both engines. The result never changes: only what is read.
  • Set KDB_NO_ZONE_MAPS=1 in the environment to turn it off (and the saved stats answers with it), for a before-and-after timing.

Example: The biggest rate is 883, so rate > 900 skips both partitions (sample data: sample)

SELECT date, max(rate) AS top_rate FROM trade_log GROUP BY date ORDER BY date;
EXPLAIN SELECT transaction_id, rate FROM trade_log WHERE rate > 900;

Result:

SELECT date, max(rate) AS top_rate FROM trade_log GROUP BY date ORDER BY date

(2 rows)

EXPLAIN SELECT transaction_id, rate FROM trade_log WHERE rate > 900

(4 rows)

Answers without reading rows

Syntax:

answer from saved stats of table t: a of p partitions from the partition list and their files' stats (...); k partitions scanned
answer from the partition list of table t (k of n partitions; no other rows read)

Some questions are answered from what KDB already knows about each partition, without loading its rows.

• Saved stats: the query has no GROUP BY, no math inside the aggregate, and a WHERE only on the time column (a comparison, BETWEEN or time IN '...'). A partition is answered from its stats when it has no unsaved changes and all its rows are inside the time range. The other partitions are read as usual: k partitions scanned. A plain SELECT count(*) FROM t also counts a partition with unsaved changes without reading it, when the changes are new rows: rows timed after (or before) every saved row of that partition, as a live feed writes them, or rows of a table without a key. A delete, or a change inside the saved time range, makes that partition read. A sum of DOUBLE values may differ in the last digit from reading every row.
• Partition list: the time value must be the same for every row of a partition, like a DATE column of a table with daily partitions.
• Notes:
  • Not on a table with computed columns, not with a symbol = ... condition, and not with first or last.
  • Set KDB_NO_PARTITION_ANSWERS=1 to turn off the partition list answers.

Example: Count, lowest, highest and total volume of every daily candle: no row is read (sample data: sample)

EXPLAIN SELECT count(*) AS candles, min(low) AS lowest, max(high) AS highest, sum(volume) AS volume FROM ochl_day;
SELECT count(*) AS candles, min(low) AS lowest, max(high) AS highest, sum(volume) AS volume FROM ochl_day;

Result:

EXPLAIN SELECT count(*) AS candles, min(low) AS lowest, max(high) AS highest, sum(volume) AS volume

(5 rows)

SELECT count(*) AS candles, min(low) AS lowest, max(high) AS highest, sum(volume) AS volume FROM och

(1 row)

Example: The days of a table with daily partitions come from the partition list

Setup:

CREATE TABLE fills (day DATE, symbol SYMBOL, qty LONG) TIMESERIES(day) PARTITION BY DAY;
INSERT INTO fills VALUES ('2026-09-08', 'CITY', 10), ('2026-09-09', 'CITY', 20), ('2026-09-09', 'VOLT', 5), ('2026-09-10', 'VOLT', 7);

EXPLAIN SELECT DISTINCT day FROM fills ORDER BY day;
SELECT DISTINCT day FROM fills ORDER BY day;

Result:

EXPLAIN SELECT DISTINCT day FROM fills ORDER BY day

(2 rows)

SELECT DISTINCT day FROM fills ORDER BY day

(3 rows)