﻿<?xml version='1.0' encoding='UTF-8'?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/"><channel><title>SQLServerCentral / SQL Server 2008 / T-SQL (SS2K8)  / FASTFIRSTROW Hint / Latest Posts</title><generator>InstantForum.NET v2.9.0</generator><description>SQLServerCentral</description><link>http://www.sqlservercentral.com/Forums/</link><webMaster>notifications@sqlservercentral.com</webMaster><lastBuildDate>Sat, 25 May 2013 12:36:25 GMT</lastBuildDate><ttl>20</ttl><item><title>RE: FASTFIRSTROW Hint</title><link>http://www.sqlservercentral.com/Forums/Topic1405298-392-1.aspx</link><description>Thanks Howard (sorry I forgot in my first reply) and Gail. </description><pubDate>Thu, 10 Jan 2013 04:03:03 GMT</pubDate><dc:creator>Jason-299789</dc:creator></item><item><title>RE: FASTFIRSTROW Hint</title><link>http://www.sqlservercentral.com/Forums/Topic1405298-392-1.aspx</link><description>[quote][b]Jason-299789 (1/10/2013)[/b][hr]It is also my understanding that while you can get data being returned faster from the initial execute you can also end up with a sub optimal plan being used, is this correct?[/quote]Correct. The point of the hint is that you want to ensure that the first few rows arrive fast and you don't mind if then entire resultset takes longer than it would otherwise. The optimiser avoids blocking operations (like sorts or hashes) as far as possible, even if they may be the lowest cost option.</description><pubDate>Thu, 10 Jan 2013 03:44:44 GMT</pubDate><dc:creator>GilaMonster</dc:creator></item><item><title>RE: FASTFIRSTROW Hint</title><link>http://www.sqlservercentral.com/Forums/Topic1405298-392-1.aspx</link><description>These are 'end user' views, and used to feed SSAS and reports, the tables are pretty small with around 100-150 million rows in, although it seems some of the developers have heard the 'good news' about this and it seems to be creeping into other areas as well.I've done some 'prelim' testing using the views with and with out the hint and the results are interesting, in that data is returning around 4 times fast without the hint.</description><pubDate>Thu, 10 Jan 2013 03:33:39 GMT</pubDate><dc:creator>Jason-299789</dc:creator></item><item><title>RE: FASTFIRSTROW Hint</title><link>http://www.sqlservercentral.com/Forums/Topic1405298-392-1.aspx</link><description>The views are used to populate the DW, rather than for end user queries? Yes, they can definitely produce sub-optimal plans as by definition, they sacrifice overall execution time in order to get the first rows out quicker. So generally, unless statistics are incorrect or there's another reason that it's "tricking" the optimiser into picking a better plan, there's nothing to gain and much to lose from the hint.The hint is generally only used for queries that an end-user is receiving the results for and implements client-side paging, to give the appearance of a more responsive system.</description><pubDate>Thu, 10 Jan 2013 03:27:25 GMT</pubDate><dc:creator>HowardW</dc:creator></item><item><title>FASTFIRSTROW Hint</title><link>http://www.sqlservercentral.com/Forums/Topic1405298-392-1.aspx</link><description>I've been doing a review of a DW project and noticed that several of the views use a WITH (FASTFIRSTROW)I need to start putting together a list of issues, but I'm unsure how to put this down as a possible issue, the first issue is a future compatibilty as I'm aware that the FASTFIRSTROW hint is being deprecated and replaced with OPTION(FAST n).It is also my understanding that while you can get data being returned faster from the initial execute you can also end up with a sub optimal plan being used, is this correct?Are there any other issues that anyone can point out.</description><pubDate>Thu, 10 Jan 2013 02:57:35 GMT</pubDate><dc:creator>Jason-299789</dc:creator></item></channel></rss>