The page only queues tasks; it never changes the database directly. Every change runs asynchronously in the background, so confirm the outcome under Tasks / history.
Table Query Ops is off by default. Set
V2_TABLE_QUERY_OPS_ENABLED to true on the backend and restart, and the page starts collecting observations.Find the table to work on
The page opens on the table list. The state buttons across the top carry their own counts and narrow the list:
The search box accepts table, Project, and Space names or IDs. Sorting is either Most slow queries or Table name. Observation window covers the last 1 hour or 24 hours, and every observation figure in the list follows that window. Observations are kept for 2 days; anything older no longer appears in the list.
Each row gives the table’s estimated rows and size, the requests and slow queries within the window, the current search method and field coverage, the number of filter/sort indexes, and the counts of pending recommendations and active tasks. Click a table name to open its detail.
About index states, next to the state buttons, explains how these counts are measured.
Read the index state
The table list and the table detail both show an index state next to the search method:
Two lines can appear below the state. Configured: pg_bigm / pg_trgm means the saved provider differs from the search method in use, and Indexed-search runtime switch: off means the index is ready but the runtime is off, so search still runs
ILIKE.
A published index does not mean every search hits it: a probe that is too short, or a field outside the coverage, still falls back to
ILIKE. This page reports the state of the index, not proof that recent requests hit it.Configure search coverage
The Search coverage tab shows the table’s current search method, how many fields are covered, and the Serving coverage of each field. Show uncovered fields narrows the list to the fields not yet included; fields marked Not eligible cannot contribute to a substring search index.Serving coverage requires published, usable index metadata and the runtime switch on; a saved configuration alone does not count. Coverage is explicit, so fields you add later are not included automatically; configure the table again to bring them in.
Analyze and dry-run runs the change without committing it and reports the covered field count, estimated rows, whether plan evidence exists, and the impact of creating or rebuilding. Tables estimated at 50,000 rows or more, or of unknown size, also require the maintenance-window acknowledgement. Then choose Confirm and queue task.
What the dialog returns is a task receipt, not a result. Close it and follow the task under Tasks / history. Submitting the same change again returns the existing task.
Manage filter and sort indexes
The Filter / sort indexes tab lists the physical indexes that serve filter predicates and ordering on this table, each with its validity, whether Teable manages it, its size, and its definition. These are managed separately from substring search indexes. Pending actions below holds the system’s index recommendations and says whether plan evidence backs each one. Review index creation shows the proposed index, the database it runs against, and the evidence; after you confirm, Teable runsCREATE INDEX CONCURRENTLY asynchronously. Large tables and tables of unknown size need the maintenance-window acknowledgement here too.
This page does not delete indexes. Unmanaged and system indexes may protect constraints or serve other workloads, so they are left alone.
Diagnose specific queries
When someone reports a slow table and no recommendation covers it, open the Query diagnosis tab and choose Analyze queries. The analysis only reads saved query shapes and available plan evidence; it creates nothing. The conclusion is one of Plan-backed index opportunities found, No index opportunity confirmed by the available plans, or Insufficient evidence. Insufficient evidence does not mean a sequential scan happened: a slow observation alone does not establish that the access path is at fault. Below it, each affected query is listed with whether it came from real traffic or a saved view configuration, and the estimated plan cost before and after the proposed index (plan cost, not milliseconds).Follow the results
The Tasks / history tab holds three parts:- Tasks: background tasks for this table, with status, attempt count, task kind, and failure reason. When a task eventually succeeded after failing, the error is labelled as a prior attempt.
- Search configuration history: the provider, status, and field list of each past coverage configuration.
- Recommendation history: recommendations that were accepted, dismissed, or superseded.
While a table has a queued or running task, the buttons for configuring search and creating indexes stay disabled. Wait for the task to finish.