The question of what Estimated Processing Time actually is comes up a lot. For example, the DBQLogTbl table carries an “EstProcTime” Value. If you are EXPLAIN-savy, then you’ve bumped up against “Estimated Time” numbers in almost every step of every query plan you’ve ever looked at. You TASM users frequently rely on “Estimated Processing Time” as a classification criteria to manage the priority that a query will enjoy. Some think Estimated Processing Time is an estimate of clock seconds, and others believe it represents CPU seconds. Here’s what it actually is.
First, it’s consistent. Estimated Processing Time comes from the same source whether it’s within Database Query Log (DBQL), EXPLAIN text or used by workload management. It represents the cost estimate the optimizer produced for a given query step, or for the entire query. Estimated Processing Time takes into account CPU, I/O, and network (BYNET) estimated costs in combination, and self-adjusts for higher-powered hardware.
The original purpose of Estimated Processing Time was to allow the optimizer to compare different costs for different database operations when building a plan. And even today, it really has no absolute meaning except within the optimizer's algorithms. However, if good statistics have been collected, estimated processing time can give you a reasonable sense of whether the query is likely to be very short or very long, or somewhere in between. Because it usually correlates with the resulting resource requirements of the request, Estimated Processing Time is a popular secondary classification criterion when using TASM, or for use with the step time threshold option when defining throttles.