Unfortunately, there's not really a way to do this "automatically" that I'm aware of.
An execution plan operator doesn't necessarily map to something in the query text. Some simple cases of this are functions and views. Imagine a simple query like this:
SELECT * FROM dbo.vwOrderDetails;
The execution plan will probably have scans or seeks against
dbo.OrderLineItems (whatever is in the view definition). But there is nothing in the plan XML that indicates those scans and seeks "map back" to
Another example would be execution plan operators that don't map easily to any specific SQL text. For instance, a
Sort operator might map to an
ORDER BY clause. But it might be a sort introduced to satisfy a
In your specific case, your best bet is probably to look at the
STUFF ... FOR XML PATH portions of your query and try to reason about which one is the node in question (maybe based on what operators are flowing into it, or based on the output list).
Another option would be to break the query up into smaller chunks that can be run separately to narrow down what is what. You could comment out
JOINs and / or items in the
SELECT list until the XML Reader TVF node disappears, and then you'll know which part of the query text it's coming from.