calgettrace improvement

calget trace reports following steps at UM or PM level

BPS - Batch Primitive Step
HJS - Hash Join Step
TAS - Tuple Aggregation step
TUS = Tuple Union step
TNS - Tuple Anex Step

Please provide explanation of this in the output of calgettrace

Also BPS can match to one of the following, please sepcify which exact BPS is being carried out in the plan printed by calgettrace.

• Single Column Scan: Scan one or more Extents for a given column based on a single column predicate, including: =, <>, in (list), between, isnull, etc.
• Additional Single Column Filters: Project additional column(s) for any rows found by a previous scan and apply additional single column predicates as needed. Access of blocks is based on row identifier, going directly to the block(s).
• Table Level Filters: Project additional columns as required for any table level filters such as: column1 < column2, or more advanced functions and expressions. Access of blocks is again based on row identifier, going directly to the block(s).
• Project Join Columns for Joins: Project additional join column(s) as needed for any join operations. Access of blocks is again based on row identifier, going directly to the block(s).
• Execute Multi-Join: Apply one or more hash join operation against projected join column(s) and use that value to probe a previously built hash map. Build out tuples as need to satisfy inner or outer join requirements. Note: Depending on the size of the previously built hash map, the actual join behavior may be executed either on the server running PM processes, or the server running UM processes. In either case, the Batch Primitive Step is functionally identical.
• Cross-Table Level Filters: Project additional columns from the range of rows for the Primitive Step as needed for any cross-table level filters such as: table1.column1 < table2.column2, or more advanced functions and expressions. Access of blocks is again based on row identifier, going directly to the block(s). When a pre-requisite join operation takes place on the UM, then this operation will also take place on the UM, otherwise it will occur on the PM.
• Aggregation/Distinct Operation Part 1: Apply any local group by, distinct, or aggregation operation against the set of joined rows assigned to a given Batch Primitive. Part 1 of This process is handled by Performance Modules
• Aggregation/Distinct Operation Part 2: Apply any final group by, distinct, or aggregation operation against the set of joined rows assigned to a given Batch Primitive. This processing is handled by the User Module.