UDF events

General
, , ,
1

UDF events

Hi Team,

We are observing UDF events for below mentioned report. Please suggest fix.



Report

Properties in Query


GetAllEligible(TIA-SIP-Work-ABC)

pegadata.pr_read_from_stream(‘.SharedReport’, “PC0”.pzInsKey, “PC0”.pzPVStream) NOT LIKE ? OR pegadata.pr_read_int_from_stream(‘.SharedReportCount’, “PC0”.pzInsKey, “PC0”.pzPVStream)


GetAllNominatedESACasesIntertek(TIA-SIP-Work-ABC)

pegadata.pr_read_from_stream(‘.AuditAssessmentDetails.IFAExtentionFlag’, “PC0”.pzInsKey, “PC0”.pzPVStream)


pyDefaultReport(TIA-SIP-Work-ABC)

pegadata.pr_read_from_stream(‘.pyWorkParty(Owner).pyUserName’
2

The fix is to remove the UDF-based properties from the report and expose those fields as database columns, then update the report to use the exposed columns instead of pr_read_from_stream or pr_read_int_from_stream. These UDF events happen because the report is reading data from the BLOB, which is slow and causes database overhead. Exposed columns let the database read the values directly, so the report runs faster and avoids UDF alerts. Expose properties like .SharedReport, .SharedReportCount, .AuditAssessmentDetails.IFAExtentionFlag, and .pyWorkParty(Owner).pyUserName in the work table or index them properly. After that, resave the report definition and make sure it only uses the exposed fields. This is the correct long-term fix for UDF events in reports.

3

User-defined functions (UDFs) to read unoptimized properties from the storage stream (BLOB) for reporting or queries is a performance anti-pattern. The recommended approach to “fix” this issue is to optimize (expose) the property as a dedicated database column