An aggregate without `GROUP BY` (such as `count`) still builds the correlated
domain to restore empty groups, so the in-memory buffer and the hash-join
restriction still apply.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With the default `correlated_subqueries_substitute_equivalent_expressions = 1`, a simple
equality correlation is substituted and no in-memory buffer is created, so `join_algorithm`
applies. Say so in the docs, and qualify the `max_rows_in_join` note the same way.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The join of the decorrelated lateral subquery is restricted to hash join only when
the left rows are shared through the in-memory buffer (the default); otherwise
`join_algorithm` decides. The `LimitBy` step only appears when the subquery has `LIMIT`.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The order depends on the query plan: with `WHERE y > 0` the second call becomes the outer loop. Require `ORDER BY` for a predictable order.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The example showed 0 for the perimeter of a 1x1 degree square line string; the current build returns
0.06981051179132045, the perimeter in radians on a sphere of radius 1. Say that the results of `perimeterSpherical`
and `areaSpherical` are on a unit sphere, in radians and steradians.
The three queries and their result tables were in one SQL block, so the block could not be run as is. Put each
query and its result in their own blocks. The results are unchanged: the current master build gives the same.
`h3EdgeAngle`, `h3EdgeLengthM` and `h3EdgeLengthKm` showed values that the current build doesn't return,
`h3ToGeoBoundary` showed the boundary of a different index than the one queried, and the `h3GetRes0Indexes`
example called it without parentheses, which fails. The results are from the current master build.
All four examples passed integer coordinates, which `flipCoordinates` rejects (it needs `Float64`), and the
"multipolygon" example was nested arrays without tuples. Use `Float64` literals, make the last example a real
multipolygon, take the results from the current master build, and say that coordinates must be `Float64`.
The documentation said that the lateral subquery "is evaluated for each
distinct combination of the left-side column values". That describes the
result, not the execution: the subquery is decorrelated into a single query
(the referenced left-side columns become GROUP BY keys if it aggregates,
LIMIT becomes LIMIT BY, and the result is hash-joined to the left rows), as
EXPLAIN shows with the step "LimitBy (LIMIT BY for decorrelated correlated
subquery)". Say so, and reword the limitations that referred to "all
evaluations".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Adds a "Third-party drivers" subsection after the example C drivers, with HyperlightPython, which runs a Python function body in a Hyperlight micro-VM restored from a snapshot for each block.
Signed-off-by: danbugs <danilochiarlone@gmail.com>
robot-clickhouse