• David Benoit (12/16/2010)


    Hey Jeff - I certainly like that function better than most that I have seen and used. One question I do have though; have you noticed that it always seems to return an estimated number of rows being 100 when looking at the execution plan? It may be the two examples that I have tested so far but the one I had passed in 158 and in the second < 20. It does far better than other functions in that they always return an estimated rowcount of 1 which really botches the execution plan when you have a large string parsed.

    I can start this as another thread but wondered if you have noticed this or something similar.

    That IS interesting. I never actually bothered to look because it's never been a performance problem on VARCHAR(8000) for me. I believe it's because E1 has real data so it can figure out E2 will produce 100 rows if not filtered but I won't know until I take a deeper dive on the execution plan.

    As a side bar... I also noticed that there's still some nasty implicit conversions in there because of ROW_NUMBER being a BIGINT. I'll have to get to playing with those one of these days.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)