> > *#2 Handling parallel execution* > > In cases of parallel execution/multi-threading, vendors should create a > separate Metrics object for each thread. The Metrics Framework will provide > a mechanism for nesting a collection of these parallel Metrics, and this > group of parallel Metrics will be automatically condensed into a single > Metrics "row". A user will then be able to easily obtain the > longest-running Metrics, all individual Metrics in the group, as well as > the number of Metrics/threads and any annotations that were added to the > group. >
Does this mean that #1 does not apply for this group or would you still have to sum all those parallel executions up to yield the parent metric? If the latter, wouldn't that be confusing since the resulting number can be larger than the total query time? If the former, what is the aggregate function used on multiple parallel execution metrics? > > The duration of the parent Metrics must include the time spent waiting for > all threads to finish executing (thus adhering to the previous guideline > regarding nested Metrics duration). > > > *Some notes on #2* > I am assuming that in cases of parallel execution, users will be most > interested in the longest-running duration, and secondarily interested in > inspecting information about all threads in aggregate (probably to identify > signs of potentially high CPU load). I'm also assuming that it will not be > a deal-breaker for vendor's to create a Metrics object for each thread. > Feedback here is especially appreciated. > > -Bob >
