FASTFIRSTROW hint

• Jeff Moden

  SSC Guru

  Points: 1004406

  More actions

  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)
  

• colin.Leversuch-Roberts

  SSC Guru

  Points: 52643

  More actions

  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/