In this post I’ll step through a few scenarios regarding row and page counts – and their associated influence on estimated CPU and I\/O cost. \u00a0I’ll be using the Credit<\/a> database to demonstrate different scenarios…<\/p>\n Starting State<\/strong><\/p>\n I’ll start off by checking the total number of reported data pages and row counts for the member table:<\/p>\n The member table has 142 data pages and 10,000 rows.<\/p>\n Next I’ll execute a simple query and check the estimated I\/O and estimated CPU of the Clustered Index Scan operator:<\/p>\n The Clustered Index Scan operator shows the following estimated costs:<\/p>\n Inflating the page count while maintaining the row count<\/strong><\/p>\n What happens if I inflate (artificially) the member table’s page count while maintaining the existing row count metadata?<\/p>\n If you’re curious about the method I’m using with ROWCOUNT and PAGECOUNT, see the SQL Server Query Optimization Team’s discussion on the subject:<\/p>\n \r\nSELECT [in_row_data_page_count]\r\nFROM [sys].[dm_db_partition_stats]\r\nWHERE [object_id] = OBJECT_ID('dbo.member') AND\r\n[index_id] = 1;\r\n\r\nSELECT COUNT(*) AS [row_count]\r\nFROM [dbo].[member];\r\n\r\n<\/pre>\n \r\nSELECT [member].[member_no],\r\n[member].[lastname]\r\nFROM [dbo].[member]\r\nOPTION (RECOMPILE);\r\n<\/pre>\n
\n
\r\n-- Please don't use this in production - for demonstration purposes only!\r\nUPDATE STATISTICS dbo.[member]\r\nWITH ROWCOUNT = 10000, PAGECOUNT = 149000;\r\n<\/pre>\n