> ## Documentation Index
> Fetch the complete documentation index at: https://docs.parable.work/llms.txt
> Use this file to discover all available pages before exploring further.

# Row search

> Find Provider records by what their text says, then read those records from their source tables.

# Row search

Row search finds Provider records by what their text says. Pool search finds which tables and columns hold a kind of data. Row search finds the records themselves: calls where a customer raised pricing, issues about an SSO login loop. Use Pool search when you do not yet know the table. Use Row search when the question is about the contents of records.

One SQL table function does the search: search\_everything. It covers the Provider Pool only, `providers.<connector>.<table>`, and only text fields a Provider has flagged for it. It takes up to three arguments, by position only: query, then scope, then limit. The query is plain text describing the records you want. The optional scope is a dotted pattern that must start with providers, the same shape Pool search uses: providers.jiracloud.\* is one Provider, providers.jiracloud.issues.body is one field. With no scope, every Provider table the session can read is searched. The optional limit is how many records to return, from 1 to 100, and it defaults to 20. Pass NULL to skip scope and still set limit. Run a search like any other SQL, with Preview a Plot, the operation that runs one query and returns its rows without saving a Report.

```sql theme={null}
SELECT table_ref, row_key, column_name, snippet, score, matched_chunks
FROM search_everything('customer raised pricing concerns', 'providers.gong.*', 20)
ORDER BY score DESC
```

Each result row is one source record, never one passage. table\_ref is the name to put in FROM. row\_key is the record's key as JSON text. column\_name is the flagged field of the best passage. span is JSON saying where that passage sits. snippet is the start of the best passage, a few hundred characters, taken from the record as the caller is allowed to read it. score is that passage's similarity, from 0 to 1, not a sum, so a long record does not outrank a short one. matched\_chunks is how many of the record's passages matched. provider is the Provider's name in the catalog.

A record a Provider Policy hides is left out, and its text never appears in a snippet. A session that cannot query the Provider Pool does not see its records. An empty result is not proof that nothing matches: a missing model policy, a policy that admits no embedding model for this search, or an index that is missing or still building all return no rows. Try again later, or use Pool search and read the table.

Searches run only in interactive queries such as Preview a Plot. A Plot cannot call search\_everything: saving one records an error on the Plot, and the Plot cannot publish until it is removed. Use a search to find records, then write the Plot's SQL against the source table.

1. Describe the records in plain words, such as customer raised pricing or SSO login loop. Narrow with a scope when you already know the Provider.
2. Keep a LIMIT. The function's own limit is the number of records, and SQL LIMIT only filters those.
3. Read the full record from the source table. row\_key is JSON text. Join a text key with json\_get\_str(row\_key, 'id'), and a numeric key with json\_get\_int, using the names inside row\_key. The join is an ordinary read of that table, so a record the search omitted stays omitted.
4. If nothing comes back, rephrase the query, widen the scope, or check with Pool search that the table exists and the Provider is connected. An empty search can also mean the index is not ready yet.

A good result names the table\_ref it used, joins back, and answers from the source rows rather than from the snippet alone.

Related Powers: Pool search, Providers, Plots. Find each by its title; do not guess stored names.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.