@CadeRoux have you looked at sys.dm_exec_query_stats?

Morning

Morning

Morning

A chairde - Morning all!

@HannahVernon Cool, let me see if that CLR time is useful.

@CadeRoux I think it should be somewhat valuable to see the proportion between the CLR time, and the other times listed; at least in aggregate. It won't show any particular run unless you clear the values for a particular query by evicting its plan before execution.

It show 41 microseconds of total CLR time, with 573767 microseconds total elapsed - which is really weird. Let me set up better comparisons with and without the calls to XmlTransform

41 microseconds is sub-millisecond timing, which I thought the DMV wasn't capable of showing.

> Time, reported in microseconds (but only accurate to milliseconds)

Lol, I know. It makes no sense.

This is SQL Server 2012, FWIW

@McNets - Check out my answer to our little array problem here - I sweated blood over this one! :-) Still, I managed to do it without any extensions, functions or C code! I'm having a bit of bother with the UPDATE though - you can take a look here if you're interested. I'll be posting your (très élégante!) function approach tomorrow as a community wiki!

Your function is here if you've changed your mind about posting it yourself? I learnt a lot going through it - thanks for that - fins aviat!

@HannahVernon I think it is working well, now to figure out how to work around this

I'm currently looking at my adhoc versions of what's running in the procs in the background, but the linking to the procs is also useful once I tweak this code enough to go back into procs. I think ultimately we are going to find this XSLT is too complex for this or the volume of rows is too high compared to the other XML processing we do.