Post reply

FASTFIRSTROW hint

  • December 13, 2007 at 2:39 pm

    #760026

    Now in case of FASTFIRSTROW..I am trying to achieve a fast response time

    It's far better to write good fast SQL with the proper indexes instead of trying to trick Mother Nature into doing optimization for you.

    --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)
    Intro to Tally Tables and Functions

  • December 14, 2007 at 5:14 am

    #760150

    sql 2005 doesn't appear to be quite so good at deciding if it should recompile a plan, although I've no direct tests to prove this only seeing what happened to Navision.

    Microsoft issued service packs to remove the fast statements from the Navision application becuase it did so much harm - we had over 500 plan guides forcing recompiles whilst we waited for the sp patch. Of course the constant recompiles caused other problems ( oh joy! ) if nothing else this should indicate the risk of using FAST - not every change or additional feature to sql server is always for the best, and quite often there's a "dark side" to such chnages, such as for FAST , varchar(max) and such.

    [font="Comic Sans MS"]The GrumpyOldDBA[/font]
    www.grumpyolddba.co.uk
    http://sqlblogcasts.com/blogs/grumpyolddba/

Viewing 2 posts - 16 through 16 (of 16 total)

You must be logged in to reply to this topic. Login to reply