Keep browsing responsive

Keep an investigation responsive by asking the source for the data you need and showing a manageable result in the browser. A slow query, a large transfer, and a slow-to-render grid are different problems, even when they all feel like a long wait.

Load what the question needs#

Start with 25 or 50 rows when exploring a table. Use Filter to reduce the requested result at the database. Search only finds text in the loaded page, so it does not make the source scan or return fewer records.

If the question concerns one record, use its key in a filter rather than increasing the page size until the record appears. If it concerns a total, a source-side aggregate can return the answer without transferring every input row.

Bound custom queries#

Choose the fields needed for the question and use an appropriate limit while exploring. Wide text or document fields can make a small row count expensive to transfer and display.

Keep the sample query separate from the final report query. A limited sample is useful for understanding values, but it does not establish a total for the whole object.

For a slow statement, use the database's explain tools to inspect the work it plans. See Query optimization for a measured comparison process.

Separate the delay#

Try a small read against the same source. If that is slow too, check connectivity, source load, and query execution. If a small result is quick but a large result is difficult to use, reduce the returned fields and page size before changing database settings.

Compare the same query under similar conditions. Record the source, query, result count, and observed time so a later change can be assessed against something concrete.

Keep diagrams focused#

Select only the objects needed for the question in Graph. Use fit view after changing the selection. A smaller diagram is easier to read and avoids spending effort laying out unrelated parts of a schema.

Continue with Performance tuning for a step-by-step diagnostic sequence.