docs: fix LATEST ON supported PARTITION BY column types

[ideoma]

Summary

The LATEST ON docs listed a fixed, inaccurate set of column types supported in PARTITION BY: SYMBOL, STRING, BOOLEAN, SHORT, INT, LONG, LONG256, CHAR, DECIMAL.

• VARCHAR was missing even though it is fully supported.
• DECIMAL was listed as supported but actually errors at query time.

Verification

Verified directly against a live QuestDB Enterprise instance by creating a table with one column of every data type and running LATEST ON ts PARTITION BY <col> for each:

• Confirmed supported: SYMBOL, VARCHAR, STRING, BOOLEAN, BYTE, SHORT, INT, LONG, LONG256, CHAR, FLOAT, DOUBLE, DATE, TIMESTAMP, UUID, IPv4, GEOHASH (plus LONG128/TIMESTAMP_NS, not user-facing types documented elsewhere).
• Confirmed unsupported (server error invalid type, only [...] are supported in LATEST ON): BINARY, ARRAY, DECIMAL.

Fix

Switched the docs from an allow-list to a deny-list, since almost every column type is supported:

columnName list used in the PARTITION BY part of the clause is a list of columns of any type except BINARY, ARRAY, and DECIMAL, which are not supported in PARTITION BY.

This is both more accurate today and less likely to go stale as new column types are added.

[github-actions]

🚀 Build success!

Latest successful preview: https://preview-565--questdb-documentation.netlify.app/docs/

Commit SHA: 7083743

📦 Build generates a preview & updates the link on each commit.

[ideoma]

PR #565 review — LATEST ON (level 2)

Verdict: approve-with-nits. Build passes. Every example and result table is correct (checked against the source and the demo instance). Nothing blocks merge. Most gaps below were already on the page before this PR.

Major (fix in this PR or right after)

File: documentation/query/sql/latest-on.md

1. Row order is not stated. Every result table is sorted by ts, so readers assume that order is promised. It is not (over a sub-query, rows come out in the order each key first appears). Add: "Output order is not guaranteed; add ORDER BY."
2. The syntax block leaves out ORDER BY / LIMIT and the (latestOnQuery) WHERE ... form. Both work, and the page uses the second form in examples. Add [ORDER BY ...] [LIMIT n] and a second labelled block for the "filter after" form.
3. Timestamp rule is stated twice and inconsistently (L23-25 vs L42-45). Keep one rule: on a table it must be the designated timestamp; over a sub-query any TIMESTAMP / TIMESTAMP_NS column works (you can also use this to pick a different column). Also say that DATE fails with not a TIMESTAMP.
4. PARTITION BY accepts only column names. Expressions (lower(symbol)) and SELECT aliases fail. Say so, and give the fix: compute the value in a sub-query first.
5. The performance section is buried and gives no fix (L144, an H4 under "Multiple columns"). Promote it to ## Performance. State that the early stop counts all values in the symbol dictionary (the list of every value ever stored). So if a symbol has no rows left, or none pass WHERE, the whole table is scanned. Link to materialized-views.md#advanced-latest-on-optimization and the index pages. Mention WHERE symbol IN (...) as the fast path. Remove the duplicate text at L106-107.
6. The page has no search terms for "DISTINCT ON" or "latest row per group". Add one line after the intro mapping it to Postgres DISTINCT ON / row_number() = 1, plus a ## See also section (latest-n-per-partition cookbook, materialized-view optimization, posting index, execution order).

Other pages that now contradict this page (outside the diff, but the PR makes the mismatch visible):

7. documentation/query/sql/select.md:336-351: old syntax block and an unqualified "requires a designated timestamp". Sync it or replace it with a link.

8. select.md TIMESTAMP section (~L370-380) and concepts/designated-timestamp.md:481: they say to use TIMESTAMP() so LATEST ON works on a sub-query. The engine does not need this; say that LATEST ON works over any sub-query as is.

9. concepts/deep-dive/sql-extensions.md:48-50: "to avoid a full scan" contradicts the new performance section. Qualify it: the early stop applies only with a single SYMBOL key.

10. Sub-query output drops the designated timestamp (LatestByLightRecordCursorFactory uses copyOfSansTimestamp). Chaining SAMPLE BY / ASOF JOIN on the result needs ORDER BY + timestamp(). Say so next to the row-order note (item 1).

11. Indexes don't speed up plain LATEST ON by default. The all-keys indexed path is gated by query.within.latest.by.optimisation.enabled=false. The index helps with WHERE sym = / IN (...). Include this in the performance rewrite (item 5).

Minor

• Error text L33-34 is a fragment. Quote the full message (<col> (DECIMAL(10,2)): invalid type, only [...] are supported in LATEST ON) or just say "an invalid type error".
• The legacy LATEST BY form is not mentioned, but four pages still use it (force-designated-timestamp, geohashes, mindsdb, cairo-engine config). Add a one-line :::note.
• Example schema: cust_id '1'/'2' and ts are weak names. Suggest account, ccy, timestamp. Merge the single-row inserts into one uppercase multi-row INSERT INTO ... VALUES (L172-179 forces horizontal scroll).
• WHERE price > 1 on FX pairs (L265) has no clear meaning. Use side = 'buy' or explain the filter.
• Execution order (L201) is a rule, not an example. Promote it and use clearer H4s ("Filter before / after LATEST ON").
• cookbook/.../sparse-sensor-data.md:130 links to select/#latest-on. Point it at /docs/query/sql/latest-on/.
• latest-n-per-partition.md:217 "Flexibility: Fast" looks like a typo for "Low".
• Ties: when two rows share the latest ts, the last row in storage order wins. Worth one line.

Nit

• "we" voice and filler (L50-53, 70, 91, 161, 185); bold **unique combination**; --note comment; mixed bullet/numbered step lists; L259 repeats L27; missing titles on L208/L227 blocks.
• title: could carry search terms, e.g. "LATEST ON: latest row per group".

What works

• Switching to a deny-list of types is accurate and future-proof. Checked against SqlCodeGenerator.prepareLatestByColumnIndexes.
• The new description (146 chars) and intro are specific and name the use case.
• The syntax block now shows the optional SELECT, the sub-query form and WHERE, and correctly adds TIMESTAMP_NS.
• The NULL-key rule, the corrected result tables and the demo-tagged queries are all verified.
• Sidebar placement and inbound links are good.

Downgraded

13 findings kept, 3 downgraded:

• "Type list incomplete (INTERVAL, NULL)": these types exist only as computed values in a sub-query, never as table columns. Fine to add a note, not a defect.
• "Deny-list will go stale; print the allow-list": the reverse is true. New types are more likely to be supported, and the PR's reasoning holds.
• "Combination example text is wrong": checked by hand. Customer 2's latest row on 04-21 is 780.2, which is filtered out, so the text is correct.

[javier]

I would remove this, as it is not part of LATEST ON (same with next line)

Suggested change

- `SELECT * FROM` can be omitted, for example

[javier]

I would remove this, as it is not part of LATEST ON (same with previous line)

Suggested change

`trades LATEST ON timestamp PARTITION BY symbol;`.