• jhgoodwin (12/26/2014)


    Let's be clear here.

    Any query that takes 30 hours to finish isn't poorly written. It's just broken. Yes, you fix that stuff.

    My normal metric for a query if it's correct, it will typically run in < 100ms if it's simple, or < 1sec if it's a report, or < 1 min if it's along the lines of a year end report done on transactional data.

    The thing is, if you do those year end reports everyday, then 1 min is for me, broken. It should be redone to be < 100ms.

    In no way should what I said be construed to say that a system with hundreds of gigs of randomly generated/stored transactional data, and crappy RBAR code can suddenly become usable if you throw more iron at it.

    Not sure if that helps, or just adds more sparks on this subject.

    Actually, that helps a lot and is more in line with what I just posted. It DID previously sound like you were saying that big iron was the "investment vs rewards" fix, especially since you stated that some of us might be wearing rose colored glasses. 🙂

    --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)