FuseQL Subquery Operators :: Kloudfuse Docs
FuseQL Subquery Operators
The subquery and compose operators enable dynamic filtering when you don’t know the exact filter criteria upfront. The inner query runs first to discover filter values, which are then applied to the outer query.
compose
Convert query results into a FuseQL filter expression. Primarily used within subquery, but can be run standalone to preview the generated filter.
Syntax
| compose <field1>[, <field2>, ...] [maxresults=<N>] [keywords]
| Parameter | Description |
|---|---|
<fields> |
Required. One or more field names to use for filter generation. Multiple fields create AND conditions within each row. |
maxresults=<N> |
Optional. Limits results used in filter (default: 2500, max: 10000). |
keywords |
Optional. Generates grep searches instead of field=value filters. |
Filter Format
Given this input table:
| field1 | field2 |
|---|---|
| value1 | value2 |
| value3 | value4 |
Running | compose field1, field2 produces:
Without keywords:
((field1="value1" and field2="value2") or (field1="value3" and field2="value4"))
With keywords:
(("value1" and "value2") or ("value3" and "value4"))
Example
Generate a filter from error levels and orgs:
source="query-service" | count by level, org_id | compose level, org_id
Input table (from count by level, org_id):
| level | org_id | _count |
|---|---|---|
| error | pisco-shared | 150 |
| info | pisco-shared | 320 |
Result from the compose operator:
((level="error" and org_id="pisco-shared") or (level="info" and org_id="pisco-shared"))
Common Use Cases
- Debug subqueries by previewing the generated filter
- Verify filter size before applying to large datasets
- Generate allowlist/blocklist filters from known entities
subquery
Execute a nested query and use its results as a dynamic filter in the outer query.
The subquery operator must always include a compose operator as its final stage. |
Syntax
[subquery: <inner_query> | compose <fields> [maxresults=<N>] [keywords]]
The subquery can be used at the start of a query, within a where clause, or in an if operator:
[subquery: <inner_query> | compose <fields>] | <outer_query>
<outer_query> | where [subquery: <inner_query> | compose <fields>]
<outer_query> | if([subquery: <inner_query> | compose <fields>], <true_value>, <false_value>) as <field>
The keywords clause is not supported with where and if operations. |
Behavior
- Executes the inner query first
- Uses
composeto transform results into a filter expression - Applies the generated filter to the outer query
Example
Filter logs by top hosts from another source:
org_id="pisco-shared" and [subquery: source="query-service" | count by host | compose host] | timeslice 20s | count by _timeslice
The inner query source="query-service" | count by host returns:
| host | _count |
|---|---|
| server-1 | 250 |
| server-2 | 180 |
The compose host operator converts this to ((host="server-1") or (host="server-2")), making the query equivalent to:
org_id="pisco-shared" and ((host="server-1") or (host="server-2")) | timeslice 20s | count by _timeslice
Common Use Cases
- Correlate errors across multiple services by user or session
- Find slow services and investigate their log patterns
- Filter one data source based on patterns discovered in another
Limitations
Subqueries are not supported in Scheduled Views.
Notes
- The outer query can be any query that returns results. Always test it before you add the inner query.
- Subqueries within
iforwhereare typically more expensive than when run as part of the search expression.