Accelerator Commands

An accelerator stores the results of an FSQL query in a table that Query hosts, so you can query them again without going back to the sources. Use one when an investigation runs many queries over the same slice of data, when you need to keep evidence after a source's own retention removes it, or when you want events from several sources in one place.

Each accelerator is also a connector with the same name. You fill it with LOAD, query it with QUERY and SUMMARIZE like any other connector, and remove it with DROP ACCELERATOR. EXPLAIN ACCELERATORS, EXPLAIN ACCELERATOR, and EXPLAIN ACCELERATOR QUOTA show what you have. Who can load, query, share, and drop an accelerator is covered in Who can do what below and in Permission Commands.

Accelerators are available when your tenant is entitled to them. Contact your Query account manager to enable them.

LOAD

LOAD QUERY <fields>
[WITH <filters>]
[SINCE <start time>] [UNTIL <end time>]
[FROM <connectors>]
[ORDER BY <attribute> [ASC|DESC] [, ...]]
[LIMIT <max results>]
[TIMEOUT <seconds>]
[APPEND] INTO <name>

LOAD runs the query and stores its results in the accelerator <name> instead of returning them. The first LOAD into a name creates the accelerator. No separate create statement is needed. The accelerator exists from the moment that LOAD starts, even if the load fails or stores nothing, and it counts toward the limit until you drop it.

-- A month of one user's sign-ins from four identity sources
LOAD QUERY authentication.**
  WITH authentication.user.name = 'jsmith'
  SINCE 30d
  FROM 'Okta', 'Entra ID', 'Active Directory', 'GlobalProtect VPN'
  INTO inc-4821-auth

The query can be any QUERY statement, including its WITH, SINCE, UNTIL, FROM, ORDER BY, LIMIT, and TIMEOUT clauses. SUMMARIZE results can't be loaded. The query runs as you, so it reads only connectors you can use, and the column masks that apply to you also apply to what it stores. Every stored record needs its time and class_uid, so a LOAD is refused if a mask hides either of them from you.

An accelerator name uses lowercase letters and digits, optionally separated by single hyphens (auth-logins-2026). It can be at most 59 characters long, quota is reserved, and names can't start with qac-, which Query uses for its own connectors. A name is refused if a connector with that name already exists.

What LOAD returns

A LOAD returns one row that describes the load, not the records it stored:

{
  "command": "LOAD",
  "success": true,
  "accelerator": "inc-4821-auth",
  "append": false,
  "load_id": "0192f3a4-7c1e-7b8a-9d2e-5f6a7b8c9d0e",
  "status": "succeeded",
  "rows_loaded": 48210,
  "rows_written": 48210,
  "objects_written": 1,
  "elapsed_seconds": 41.2,
  "schema": [
    {"class_name": "Authentication", "path": "user.name"},
    {"class_name": "Authentication", "path": "src_endpoint.ip"}
  ],
  "warnings": [],
  "error": null
}

schema lists the fields that the load stored, and status says how the load ended:

A load that fails returns an error instead of a row. The error names the load ((load <load_id>)) so you can find it in EXPLAIN ACCELERATOR.

A load is stored whole or not at all. If anything stops the query before every record is written, the load is aborted and nothing is stored. The causes include the query's TIMEOUT, the row limit, and a cancelled request. This differs from a plain QUERY, where a TIMEOUT returns the results gathered so far. The one exception is a connector of the main query that fails while others answer. The rows from the other connectors are stored, and the failure is reported in warnings. A connector that fails inside a subquery aborts the load instead, because the query's filter would be incomplete.

Adding to an accelerator with APPEND

A plain LOAD into an accelerator that already holds data, or that has a load in progress, is refused, so an accelerator is never replaced by mistake. To add rows, use APPEND:

LOAD QUERY authentication.**
  WITH authentication.user.name = 'jsmith'
  SINCE 1d
  APPEND INTO inc-4821-auth

Each APPEND is a separate load in the accelerator's history. Rows aren't deduplicated, so running the same APPEND twice stores its results twice. An append can store fields that earlier loads didn't, and the accelerator's fields are then the union of every load's fields.

To replace an accelerator's contents, DROP it and LOAD it again. An accelerator whose loads all failed or were aborted holds no data, and a plain LOAD into it is allowed.

Limits

Two limits bound how much a tenant can store. EXPLAIN ACCELERATOR QUOTA shows the values for your tenant.

• Accelerators per tenant: 10 by default. A LOAD that would create one more is refused before its query runs. Drop an accelerator you no longer need, or ask Query to raise the limit.

• Rows per load: 10,000,000 by default. A load whose query returns more rows than this is aborted, and nothing from that load is stored. Add a LIMIT to load only the first rows.

Querying an accelerator

Query an accelerator by its name, exactly as you would any connector:

QUERY authentication.user.name, authentication.src_endpoint.ip
  WITH authentication.status_id = FAILURE
  FROM inc-4821-auth

SUMMARIZE COUNT authentication
  WITH authentication.status_id = FAILURE
  GROUP BY authentication.user.name
  FROM inc-4821-auth

EXPLAIN CATALOG FROM <name> shows which fields an accelerator holds.

EXPLAIN ACCELERATORS

EXPLAIN ACCELERATORS

EXPLAIN ACCELERATORS lists the accelerators that you can see. Each entry has the accelerator's name and connection, its row count and event classes, its retention, who created it and when, and the status and time of its most recent load.

EXPLAIN ACCELERATOR

EXPLAIN ACCELERATOR <name>

EXPLAIN ACCELERATOR shows one accelerator and its loads, most recent first. Each load has its id, status, the statement that produced it, when it opened and completed, the rows it wrote and stored, any malformed records, who ran it, any error, and when retention will delete its rows.

A load's status is open while its query runs, ingesting while Query stores its rows, and then succeeded, failed, or aborted. A load that was opened but never finished, for example because the worker running it stopped, is eventually marked aborted, so it doesn't block a plain LOAD for good. Use this command to follow up on a LOAD that returned ingesting. While a load is ingesting, rows_written is the only count it has, because rows_loaded is set when it finishes.

EXPLAIN ACCELERATOR QUOTA

EXPLAIN ACCELERATOR QUOTA

EXPLAIN ACCELERATOR QUOTA shows how many accelerators your tenant has against its limit, the rows-per-load limit, whether the tenant is entitled to accelerators, and the retention that applies to them. Any member of the tenant can run it, because it names no accelerators.

DROP ACCELERATOR

DROP ACCELERATOR <name>

DROP ACCELERATOR deletes the accelerator, its connector, and all of its stored rows. A load that is still running is cancelled. A drop can't be undone.

Retention

Your tenant's entitlement sets how long accelerator data is kept, as a number of hot days and a number of cold days. Rows move from hot to cold storage after the hot days and are deleted after both have passed. They can still be queried while they're in cold storage. You can't set or extend an accelerator's retention.

Retention counts from when a load stored its rows, not from the events' own time. A load of last month's events keeps them for the full retention period, and each APPEND has its own expiry. EXPLAIN ACCELERATOR shows when each load's rows will be deleted.

Who can do what

An accelerator is visible only to the people it's shared with. Unlike other connectors, it isn't readable by every member of the tenant. Its creator and tenant admins can use and manage it. Everyone else needs a grant, and only a tenant admin can give one.

An accelerator must be created by a user. A team-level API key can't create one, because the accelerator's permissions are granted to the user who creates it.

See Permission Commands for how to share an accelerator and delegate its management, and for a known limitation of sharing.