Closed
Reining in runaway reports
Like Del Shannon, I've got a little runaway. But for me, it's a runaway report, one of the supplied ones (see Running report pyElapsedStatusTrend causing memory issues?)
I'm wondering if we can produce a list, for each report, focusing on whether it could potentially consume too much time/CPU.
- Is paging not used?
- What is the max rows?
- What source tables is this coming from?
- What are the number of records in the source table?
- How long does a count(*) using the standard
- What calls this (other rule, or user directly), and how are parameters supplied?
Posted: 10 years ago
Pegasystems
IN
Unfortunately, just looking at the report doesn't suffice because APIs like pxRetrieveReportData or ShowView can actually modify what is defined in the report to something else causing a different query to get generated.
Also, the same report can produce different queries if the RHS for a filter condition or join condition happens to be empty, in which that condition is completely ignored.
While what you have suggested is a good start, we can actually look at getting better in this probably by looking at report statistics
https://community.pega.com/sites/default/files/help_v718/procomhelpmain.htm
https://community.pega.com/sites/default/files/help_v718/procomhelpmain.htm