A LIMIT that applies where you write it
I asked for a way to cap rows read per table inside a many-JOIN query. The maintainers liked the problem, doubted every syntax, and the issue was closed as not planned.
Source: github.com
The argument for this request is in LIMIT could do more. This page is only the history and status.
I asked for a way to cap the rows read from one table inside a many-JOIN query, so you can sample while developing without wrapping each table in a subquery. My sketches were FROM events(100) and a LIMIT placed before the joins; a commenter suggested reusing SAMPLE.
The maintainer’s answer on 2022-09-04 was a careful no for now. FROM my_table(100) is too ambiguous because it looks like a table function; a second LIMIT before the joins “may be OK, but looks too surprising”. He floated TAKE 10, SAMPLE ANY 10 and PRQL integration, and concluded: “I would postpone implementation before more motivation for this task will appear.” In February 2025 another user pointed out that a parameterised view covers part of it, and the issue was closed the same day as not planned.
Nothing of the proposed syntax exists. On 26.4, SELECT * FROM numbers(100) LIMIT 3 ORDER BY number is still a syntax error. The parameterised view is the supported workaround:
CREATE VIEW head_of_events AS SELECT * FROM events LIMIT {n:UInt32};
SELECT count() FROM head_of_events(n = 10); -- 10 rows, joinable like any table
Status: declined. Nobody argued the problem away; nobody agreed on a syntax. See also Feature requests worth making.
Discussion
Comments live in GitHub Discussions. Sign in with GitHub to join in.