The document discusses how query runtime is calculated in Netezza and some limitations. Query runtime reported in $v_hist_queries includes queue time, GRA time, and prep time, but not other gaps between steps. Looking deeper at plan level shows times captured between steps like submit and start, but gaps exist as well. To get a full picture of runtime, one needs to account for these gaps by summing all plan times and gaps between query submit and end.

1. Netezza – Query runtime using
plans
Rashmi Malik

2. Query run time
• The first place where we look for a query’s run time is the value provided in Netezza’s history view
“$v_hist_queries”.
• The view “$v_hist_queries” calculates run time for a query as:
“end time – submit time” found in query level history tables.
• Though, that is the actual time that the user waited for the results, it does not necessarily reflect
the actual execution time of the query. For starters, it is calculated using “submit time”, and not
something like “start time”.
• There is a bit of work that goes on after the query is submitted, and before it actually starts.
• Netezza reports some of this “work” in the view $v_hist_queries’ columns such as “queue time”,
“GRA time”, “Prep time”.
• So can we then assume that the actual runtime is: runtime – (queue time + GRA time + Prep time)?
Well, for most of the audience, this is more or less a fair value of the actual runtime. However, if
one was to calculate the runtime at a deeper level, using plans, then it starts to get more
complicated, and we’ll see that some values are missing from Netezza’s history tables.

3. Going one level deeper from query to plans
• Netezza calculates the values in the view $v_hist_queries using the numbers in
query and plan history tables.
• A query can have multiple plans associated with it. Though, it will only have
one plan file.
• Each plan corresponds to either a “meta data” query fired depending upon the
client issuing the query, or to the actual query fired by the user.
• Most of the stages in a plan’s (main or other) lifecycle are captured/recorded
in Netezza history tables using timestamp values, as follows:
– Submit time – The time the plan was submitted.
– Queue time – The time the plan went in Queue state.
– Prep time – The time the plan went in Prep state.
– GRA time – The time the plan requested for resource allocation.
– Start time – The time the plan began execution.
– End time – The time the plan finished execution.
• However, some time intervals are not captured in history tables…

4. Time gaps - query and plan history
• There are a few stages, where time is spent but not captured during
execution of query/plans. These are:
– The time between query submit time and the first plan’s submit time.
– The time between a plan’s end time and the next plan’s submit time.
Let’s call this “pre-submit” time for the next plan.
– The time between the last plan’s end time, and query’s end time.
• This is explained in the next diagram…

5. Query and Plan history – times captured
QUERY_PROLOG QUERY_EPILOG
query
submittime
Plan
submittime
Plan
queuetime
Plan
preptime
Plan
gratime
Plan
starttime
Plan
submittime
Plan
queuetime
Plan
preptime
Plan
gratime
Plan
starttime
…
…
…
Plan
endtime
Plan
endtime
query
endtime
PLAN_PROLOG PLAN_EPILOG
…
…
…
Unaccounted time gap
time gap – either side can be
greater.
“Pre-submit” time, either side can be greater

6. So how do we arrive at runtime?
• When we add up all the available and elusive/missing time intervals at plan
level, and roll it up for a query, it matches the “runtime” reported in
$v_hist_queries. i.e.
query end time – query submit time
=
query submit time to first plan submit time gap
+ Σ (all plan times reported in history tables + time gap between this plan’s end time
and next plan’s submit time) over all plans for a query
+ last plan end time to query end time gap
• Adding this up is important to ensure when we fetch time from plan files, we
are not missing out any prospective “run time”.
• Though, it is open to interpretation/definition, one of the run time calculation
can be: sum of all plan files’ runtime + the time it takes from the last plan to
end till query end. This is shown in the next diagram.

7. As calculated in
$v_hist_queries
Queue time in
$v_hist_queries
QUERY_PROLOG QUERY_EPILOG
query
submittime
Set-up time Queue time Prep time GRA time Run time*
Plan
submittime
Plan
queuetime
Plan
preptime
Plan
gratime
Plan
starttime
Plan
submittime
Plan
queuetime
Plan
preptime
Plan
gratime
Plan
starttime
…
…
…
Plan
endtime
Plan
endtime
query
endtime
PLAN_PROLOG PLAN_EPILOG
…
…
…
Unaccounted time gap
time gap – either side can
be greater.
“Pre-submit” time, can be negative or positive
Suggested
definition