Pagination for large SQL result sets in GoLand

The problem: a SELECT * that won't stop

You open GoLand’s Database tool window, write SELECT * FROM orders, and run it against a reporting table with millions of rows. The result pane starts fetching, IDE memory climbs, and the UI becomes unresponsive. You only needed to spot-check recent data, but the query has no bound, so the driver attempts to return everything.

Use the built-in pagination controls

GoLand’s SQL editor includes pagination controls in the result set pane. Instead of pulling the full result set, you add a page size and offset to the query so the database returns only a slice of rows. The IDE renders that slice, and you can move forward or backward through pages without reloading the whole table.

This behavior depends on the underlying JDBC driver and database dialect. PostgreSQL and MySQL typically support LIMIT and OFFSET. SQL Server uses OFFSET ... FETCH NEXT in newer versions, while older drivers may not expose pagination at all. If the driver does not translate the clause, GoLand sends the query as written and the database decides what to return.

Worked example: page through an orders table

1. Open the Database tool window in GoLand and expand your data source.
2. Open a SQL console or scratch file.
3. Run a bounded query. Replace <schema> and <table> with your actual identifiers:

SELECT id, customer_id, total, created_at
FROM <schema>.<table>
ORDER BY created_at DESC
LIMIT 50 OFFSET 0;

Run this in the GoLand SQL console. You need read access to the table; no schema changes are made, so there is no rollback step.

After execution, the result set pane shows a pagination toolbar. Use the next or previous arrows, or change the page size, to request another slice. To see the next 50 rows:

SELECT id, customer_id, total, created_at
FROM <schema>.<table>
ORDER BY created_at DESC
LIMIT 50 OFFSET 50;

Expected check: the row count in the result pane should match the LIMIT value (50), and the OFFSET should skip the rows already shown. If the pane returns all rows or a syntax error, your driver or database version does not support that clause.

Trade-offs and limitations

• OFFSET performance degrades on deep pages. Scanning and discarding 100,000 rows to reach page 2,000 is slower than reaching page 1. For very deep pagination, consider a keyset cursor such as WHERE created_at > :last_seen instead of OFFSET.
• IDE memory still matters. Even paginated result sets are rendered in GoLand’s table view. Rendering thousands of columns or wide text fields on a machine with limited RAM can slow the editor.
• Driver differences. Pagination syntax is not universal. Verify behavior against your specific database and driver version before relying on it in a debugging workflow.

Verify it works in your environment

1. Run SELECT COUNT(*) FROM <schema>.<table> to know the total row count.
2. Run the paginated query above with LIMIT 10 OFFSET 0.
3. Click the next-page control in GoLand’s result pane and confirm the query changes to OFFSET 10 and returns the next slice.
4. Compare the first five values against a native SQL client such as psql or mysql to confirm consistency.

Closing

GoLand’s database pagination is useful for spot-checking large tables without freezing the IDE, but it is not a substitute for server-side cursors when you need to scan millions of rows efficiently. Start with LIMIT and OFFSET, verify the driver honors them, and switch to keyset pagination if deep offsets become slow.