DBeaver result‑set truncation: distinguishing Max rows, database LIMIT, and driver fetch size

Confirmed behavior

• Max rows (UI) – DBeaver’s Max rows preference (default 200) limits the number of rows displayed after the JDBC driver has delivered the full result set. It is configurable in Preferences ▸ General ▸ Result Sets.
• Database LIMIT/OFFSET – An explicit LIMIT/OFFSET clause in the SQL statement truncates the result set on the server before any rows reach the driver.
• Driver fetch size – Statement.setFetchSize() (or the driver‑specific default) only controls how many rows are transferred per network round‑trip; it never changes the total row count delivered to the UI.

What DBeaver surfaces today

DBeaver does not provide a dedicated API or UI badge that tells you which mechanism caused the visible cut‑off. You must infer the source from three observable artifacts:

1. The exact statement sent to the server (available via the Show executed query button or the query history).
2. The current Max rows setting in Preferences.
3. Driver‑level logging of setFetchSize calls and network round‑trips (enabled under Preferences ▸ Database ▸ Driver properties ▸ Log SQL and Log fetch size).

Programmatic detection steps

1. Run the query in the SQL Editor.
2. Click Show executed query (toolbar icon) or open History to capture the final SQL text that the server received.
3. Search that text for a LIMIT / OFFSET clause. If present, the database is the truncation source.
4. If no LIMIT appears, open Preferences ▸ General ▸ Result Sets and note the Max rows value.
5. Count the rows shown in the grid (the status bar displays “Rows: N”). If N == Max rows and step 3 found no LIMIT, the UI limit is the cause.
6. Otherwise, enable driver logging (Preferences ▸ Database ▸ Driver properties ▸ Log SQL + Log fetch size), re‑run the query, and inspect the log for setFetchSize calls. A fetch‑size value that matches the observed batch size confirms driver‑level batching, but remember it does not limit total rows.

Version‑specific notes

• DBeaver ≥ 23.0 – The “Show executed query” view also reveals any LIMIT that the UI automatically injects when the Limit rows toolbar toggle is enabled.
• Earlier versions – Only the raw statement you typed is shown; an automatic UI‑added LIMIT is invisible unless you check the history after execution.

One missing detail that changes the recommendation

Are you connecting through a proxy, connection pool, or middleware that may rewrite the query (e.g., injecting a hidden LIMIT)? If yes, the executed‑query view in DBeaver will not show that rewrite, and you must capture the statement on the server side (e.g., via pg_stat_statements or the DB’s query log).