Vadim wrote:
> Ok. If you feel that QueryIds is easier way to go then do it.
> In any case some preprocessing of plan tree just before execution
> will be required.
> BTW, why not use CommandIds ?
CommandId is the order in which plans get executed and
snapshots created. But it isn't the order in which the plans
got created. There could easily hundreds of CommandId's been
created until a deferred query executes. Some of it's RTE's
must get the QuerySnapshot and scanCommandId of an earlier
executed plan. But at the time it will be saved for deferred
execution, I cannot foresee the CommandId it's parents will
get.
And the case of cascaded rules? Initial query fires rule
action 1 which in turn fires rule action 2. Now initial query
executes and fires trigger which executes it's own commands.
Thus, the parent of action 2 will not get the second
CommandId of the transaction.
A plan get's associated with a CommandId at the time it's
execution starts. So it's useless to tell the relationship
between RTE's.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
