Issue

When a user opens an Insight from a landing page or dashboard, the error "Table data took too long to fetch" is displayed, and the table either loads no data or loads only partial data.

Symptoms and Impact 

• Data fails to load. 
• Query execution times exceed 50 seconds, surpassing the default 10-second timeout. 

The problem is most pronounced on tables with a large number of rows (hundreds of thousands or more).  

Chart-type Insights expose a "Try again" button when the initial 10-second threshold is exceeded, but table-type Insights do not invoke the extended-timeout retry path and fail immediately. 

Steps to Reproduce

1. Create an Insight on a class that is backed by a large database table (for example, Assign-Workbasket). 
2. Configure one or more filter conditions on columns such as assigned Operator ID or Assignment Status. 
3. Open the Insight from a landing page or dashboard while logged in as a user. 
   • Result: The browser network log shows the data-fetch request timing out after approximately 10 seconds. 
4. Observe the error message displayed in the Insight widget. 
   • Result: The error "Table data took too long to fetch" is shown. Data is absent or partially loaded. 

Root Cause

Pega Platform™ applies ignoreCase=true by default on Insight filter requests to support case-insensitive user input. At the database layer this causes the platform to wrap the left-hand side of each filter condition in a SQL UPPER() function (for example, UPPER("PC0"."pxassignedoperatorid") = ?).  

Because the UPPER() expression does not match any standard index on the column, the database engine cannot use existing indexes and resorts to a full table scan. On large tables, query execution can exceed 50 seconds, consistently surpassing the platform's 10-second synchronous fetch timeout for Insights. A secondary gap exists: the useExtendedTimeout retry mechanism (which allows up to 40 additional seconds) is not invoked for table-type Insights when the initial timeout is exceeded, unlike chart-type Insights which expose a "Try again" button. 

Solution

The UPPER() behavior is expected product behavior. The absence of an option to selectively disable it or of a function-based index created out of the box is a documented product feature gap which is planned to be addressed in a future Pega Platform release.   

The following steps resolve or mitigate the issue.

Pega Cloud deployments

The preferred resolution is to create a function-based index on the affected table so that the database engine can satisfy the UPPER()-wrapped query without performing a full table scan. 

Raise a Cloud Change Request for the Cloud DBA team to create appropriate function-based indexes for those columns. Validate the affected Insights after index creation. 

On-Prem users must work with their DBA and apply appropriate indexing based on the property used. 

Steps to identify and remediate additional affected Insights:

1. Enable DB Query events in Pega Tracer and reproduce the timeout to capture the exact SQL query and bind variables. 
2. From the captured query, identify every column to which UPPER() is applied (for example, pxassignedoperatorid, pyassignmentstatus). 
3. Create a function-based index for each affected column. For example, on the pc_assign_workbasket table, an index keyed on UPPER(pxassignedoperatorid) allows the database engine to use the index even when the column is wrapped in UPPER(). 
4. After the change, reopen the affected Insights and confirm that data loads without error. 

Repeat steps 1–4 for each additional Insight that triggers the same timeout.

Local Change

If creating a function-based index is not immediately feasible, you can remove the case-insensitive behavior from the Insight query for the affected filter fields. When the UPPER() function is no longer applied to a filtered column, the database engine can use the standard index on that column, and query performance typically returns to an acceptable level. Note that this makes the filter case-sensitive; verify that the filtering behavior still meets business requirements before applying this change in production.