Diagnose slow work

A slow action can be delayed by database execution, network transfer, or browser rendering. Identify which part is slow before increasing limits or changing connection settings.

Compare a small request#

Repeat the action with a modest page size or a query that returns a few narrow columns. Use a known identifier as a filter if possible. Compare this with the original request on the same connection.

If the small request is fast, look at the original result's row count and width. Large text or document fields can make a small number of records expensive to transfer and display. Select only the fields needed for the task.

A query's row limit does not guarantee a cheap database operation. The source may still need to scan, join, or sort many records before returning that limited result.

Check the source's execution#

Run an equivalent bounded query through another database client from the same network. If it is slow there too, inspect the query and the source's workload. Use a source-supported query plan to understand scans, joins, and sorts.

Check the engine's documentation before using plan options that execute the query. Query optimization explains how to approach that check.

Separate transfer and display work#

If the database responds quickly but the browser remains busy, reduce the result width and page size. For Graph, select the objects involved in the investigation rather than rendering the entire schema.

For an export, check its scope first. A whole-object export can read far more data than the grid page you were viewing. Use a bounded query result for a report and native tools for large bulk transfers or full backups.

Record the evidence#

Keep the query or action, source type, approximate result size, observed delay, and relevant redacted logs. Note whether the small comparison request and another client were also slow. This gives the next person enough evidence to investigate the right layer.

Continue with Sorting and pagination, Monitoring, or Troubleshooting.