Problem
I need to query a large amount of data to my application window and use paging to view it. The query itself takes a long time to process and I do not want to repeat it every time I have to fetch a page. Also, the number of rows in the result set could be huge, so I am often fetching a page from the end of the result set. I can't use the default paging because I wait a long time until I get the data back. What are my options?
Solution
There are few possible solutions out there for paging through a large result set. In this tip, I am going to focus on three examples and compare the performance implications. The examples are:
- Example 1 - I use a temporary table (#temp_table) to store the result set for each session.
- Example 2 - I use a Common Table Expression (CTE) to page through the result set.
- Example 3 - I populate a global temporary table to store the complete result set.
The first two examples are similar to some of the most commonly used paging stored procedure options, the third example is my own extension which I wanted to show for comparison in this specific case of a complex query with a large large result set.
Example #1 - Using a session temporary table (#temp_table)
In this stored procedure, I create the temporary table and insert only the relevant rows into it based on the input parameters:
CREATE PROCEDURE dbo.proc_Paging_TempTable ( @Page int, @RecsPerPage int ) AS -- The number of rows affected by the different commands -- does not interest the application, so turn NOCOUNT ON SET NOCOUNT ON -- Determine the first record and last record DECLARE @FirstRec int, @LastRec int SELECT @FirstRec = (@Page - 1) * @RecsPerPage SELECT @LastRec = (@Page * @RecsPerPage + 1) -- Create a temporary table CREATE TABLE #TempItems (RowNum int IDENTITY PRIMARY KEY, Title nvarchar(100), Publisher nvarchar(50), AuthorNames nvarchar(200), LanguageName nvarchar(20), FirstLine nvarchar(150), CreationDate smalldatetime, PublishingDate smalldatetime, Popularity int) -- Insert the rows into the temp table -- We query @LatRec + 1, to find out if there are more records INSERT INTO #TempItems (Title, Publisher, AuthorNames, LanguageName, FirstLine, CreationDate, PublishingDate, Popularity) SELECT TOP (@LastRec-1) s.Title, m.Publisher, s.AuthorNames, l.LanguageName, m.FirstLine, m.CreationDate, m.PublishingDate, m.Popularity FROM dbo.Articles m INNER JOIN dbo.ArticlesContent s ON s.ArticleID = m.ID LEFT OUTER JOIN dbo.Languages l ON l.ID = m.LanguageID ORDER BY m.Popularity desc -- Return the set of paged records SELECT * FROM #TempItems WHERE RowNum > @FirstRec AND RowNum < @LastRec -- Drop the temp table DROP TABLE #TempItems -- Turn NOCOUNT back OFF SET NOCOUNT OFF GO |
Example #2 - Using a Common Table Expression (CTE)
In this example, I use a CTE with the ROW_NUMBER() function to fetch only the relevant rows:
CREATE PROCEDURE dbo.proc_Paging_CTE |
Example #3 - Using a global temporary table to hold the whole result
In this example, I use a global temporary table to store the complete result set of the query. In this scenario, this temporary table will be populated during the first execution of the stored procedure. All subsequent executions of the stored procedure will use the same temporary table. The idea behind this approach is that, when using a Global temporary table, other sessions can also use the same table (if they are aware of the GUID and need the same data). In order to drop the temporary table, you will have to either drop it explicitly or disconnect the session.
If this approach does not work for you, you could use the same technique method to create "temporary" tables in your user defined database with a unique extension. One specific scenario when this technique could be useful is when the tempdb database is already being a bottleneck. If that is the case, with this approach you can always create a dedicated database for these tables. Just do not forget to drop the temporary objects when they are not required.
CREATE PROCEDURE dbo.proc_Paging_GlobalTempTable |
No comments:
Post a Comment