Issue

Users encounter severe performance degradation in jobs involving the pzPerformArchiveUsingPipeline activity resulting in extremely slow purge operations. 

Symptoms and Impact

Archival jobs copy data successfully, but purge operations are limited to one case every 15-50 seconds. This low throughput causes the database to grow unsustainably and triggers performance alerts (PEGA0005). 

Steps to Reproduce

In an environment with high volumes of field-level audit data:   

1. Use Job scheduler pyPerformArchiveUsingPipeline to purge old work objects. 
2. Configure an archival policy via the Admin Studio pipeline page to purge these resolved cases. 
3. Monitor the PegaRULES log file for PEGA0005 alerts and observe the slow throughput of the job (1-2 cases per minute).  

Root Cause

This is a bug which causes an inefficient DELETE query on the pc_FLAudit_ table, resulting in extremely slow purge operations. 

The archival process pzPerformArchiveUsingPipeline is designed to purge and archive old work objects. However, in environments generating very high volumes of  field-level audit data, the pc_FLAudit_XXXXXX table becomes extremely large.  

The purge operation is hindered by a specific DELETE query that uses a leading wildcard LIKE '%...' condition on the pxHistoryReference column. This query structure prevents the database from utilizing the existing non-clustered index on pxHistoryReference, resulting in full table scans and severe performance degradation.  

Solution

Update to the following Pega Infinity releases where the issue is resolved: 

• Pega Infinity '26.1 
• Pega Infinity '25.1.3   
• Pega Infinity ‘24.2.5 

Users on Pega Infinity '24.1.4 can request HFIX-D1102.

References

Job schedulers and queue processors included with Pega Platform 

Enabling field-level auditing