When a query rule is slow, I approach it systematically by checking rule dependencies, data volume, query design and indexing.

Check Rule Dependencies First

Before optimizing the query itself, I analyze where and how the rule is used.

Actions:

Identify dependent interfaces, expressions, and process models
Confirm what data is actually required by the consumer
Avoid over-fetching data just because the query rule was reused

If the UI or process needs only a single value or record, I adjust the query accordingly instead of returning a full dataset.

Control Data Volume with Pagination

Fetching unnecessary rows is one of the biggest performance killers.

Actions:

Use pagination in all queries
Never use batchSize: -1 unless absolutely required
Limit batch size based on actual usage

Example (Fetch only one record):

a!pagingInfo(

startIndex: 1,

batchSize: 1

)

This ensures the database returns only one row, not the entire table.

Fetch Only Required Columns

Many slow queries fetch all columns even when only a few are needed.

Actions:

Use rule inputs to decide required fields
Pass selection columns as rule inputsUse selectionFields to fetch minimal data

Example:

a!queryEntity(

entity: cons!EMPLOYEE,

query:a!query(

selection: if(

a!isNullOrEmpty(ri!selections),

null,

a!querySelection(

columns: {

a!forEach(

items: ri!selections,

expression: a!queryColumn(field: fv!item, alias: fv!item)

)

}

)

)

)

This makes the rule reusable and optimized across multiple use cases.

Adding Indexing

If I observed that the performance issue was mainly caused by frequent filtering on a specific column. For example username

a!queryEntity(

entity: cons!EMPLOYEE,

query: a!query(

filter: a!queryFilter(

field: "username",

operator: "=",

value: ri!username

)

)

)

Adding an index to the frequently used column can significantly improve query performance.

Sample code for adding Index

CREATE INDEX idx_employee

ON employee(username);

If Data source is a VIEW

I will follow same the above steps for view. In additional, I will follow this below steps as well

Optimize Query Design

Remove unnecessary filters and joins
Avoid complex calculations inside sub queries
Push heavy logic to the database layer when possible

Optimize Joins

Remove joins that are not required by the UI
Convert LEFT JOIN to INNER JOIN when business rules allow
Add indexes on join columns

In summary, I first check rule dependencies to understand actual data usage. I then optimize the queryEntity—whether it queries a table or a database view—by limiting rows using pagination, fetching only required columns, simplifying joins, and ensuring proper indexing on underlying tables.