sp_BlitzIndex: Warn about partitioned tables that don't have incremental statistics

[ReeceGoding]

Closes #3699. Everything went as I described there.

Screenshot

Test Script

This takes more than 10 minutes on my machine, because partitioning the Posts table is slow.

/* On a fresh StackOverflow 2010 copy, there is nothing new here */
USE [StackOverflow2010];
EXEC sp_BlitzIndex @SkipStatistics = 0, @Mode = 0;
EXEC sp_BlitzIndex @SkipStatistics = 1, @Mode = 0;
EXEC sp_BlitzIndex @SkipStatistics = 1, @Mode = 4;
EXEC sp_BlitzIndex @SkipStatistics = 0, @Mode = 4;

/* Now let's partition */
CREATE PARTITION FUNCTION PfDates (DATETIME)
AS RANGE RIGHT
FOR VALUES
    (NULL, '20070101', '20080101', '20090101',  '20100101');
GO

CREATE PARTITION SCHEME PsDates
AS PARTITION PfDates
ALL TO ([Primary]);
GO

ALTER TABLE [dbo].[Votes] DROP CONSTRAINT [PK_Votes__Id]

ALTER TABLE [dbo].[Votes] ADD  CONSTRAINT [PK_Votes__Id] PRIMARY KEY CLUSTERED 
(Id, CreationDate)
ON PsDates(CreationDate);

/* Make sure the various caches know about votes, or else sp_BlitzIndex can't see it. */
SELECT TOP (1000) *
INTO #Bye
FROM [StackOverflow2010].[dbo].[Votes]

/*
    Now try the old calls again
*/
/* Reports nothing from the new stuff. */
EXEC sp_BlitzIndex @SkipStatistics = 0, @Mode = 0;
/* Reports nothing from the new stuff. */
EXEC sp_BlitzIndex @SkipStatistics = 1, @Mode = 0;
/* Reports nothing from the new stuff. */
EXEC sp_BlitzIndex @SkipStatistics = 1, @Mode = 4;
/* Has the new warning. */
EXEC sp_BlitzIndex @SkipStatistics = 0, @Mode = 4;

/* Now add an incremental statistic. */
CREATE STATISTICS FullscanIncremental
ON [StackOverflow2010].[dbo].[Votes]
(VoteTypeId)
WITH FULLSCAN, INCREMENTAL = ON;

/* Still mentions the new row, but it is different. */
EXEC sp_BlitzIndex @SkipStatistics = 0, @Mode = 4;

/* Make the old non-incremental statistic be incremental. */
UPDATE STATISTICS [dbo].[Votes] (PK_Votes__Id)
WITH FULLSCAN, INCREMENTAL = ON;

/* New row is gone. */
EXEC sp_BlitzIndex @SkipStatistics = 0, @Mode = 4;

/* Add a few more tables and try silly things, just to see if anything breaks */
ALTER TABLE [dbo].[Posts] DROP CONSTRAINT [PK_Posts__Id]

ALTER TABLE [dbo].[Posts] ADD  CONSTRAINT [PK_Posts__Id] PRIMARY KEY CLUSTERED 
(Id, CreationDate)
ON PsDates(CreationDate);

ALTER INDEX [PK_Posts__Id] ON [dbo].[Posts] REBUILD WITH (STATISTICS_INCREMENTAL = ON);

SELECT TOP (1000) *
INTO #No
FROM [StackOverflow2010].[dbo].[Posts]

/* Presents nothing of interest, since all of our statistics are incremental. */
EXEC sp_BlitzIndex @SkipStatistics = 0, @Mode = 4;

ALTER TABLE [dbo].[Comments] DROP CONSTRAINT [PK_Comments__Id]

ALTER TABLE [dbo].[Comments] ADD  CONSTRAINT [PK_Comments__Id] PRIMARY KEY CLUSTERED 
(Id, CreationDate)
ON PsDates(CreationDate);

CREATE STATISTICS Increm
ON [StackOverflow2010].[dbo].[Comments]
(PostId)
WITH INCREMENTAL = ON;

CREATE STATISTICS NotIncrem
ON [StackOverflow2010].[dbo].[Comments]
(PostId);

CREATE STATISTICS NotIncrem2
ON [StackOverflow2010].[dbo].[Comments]
(PostId);

SELECT TOP (1000) *
INTO #NoNo
FROM [StackOverflow2010].[dbo].[Comments]

/* Shows the Comments table, as expected */
EXEC sp_BlitzIndex @SkipStatistics = 0, @Mode = 4;

Notes

• I'm a little bit worried about the documentation's table getting too wide, but the only fix would be Brent putting some /go/ content in.
• I haven't bothered to test on multiple databases, but I don't see why anything would break.
• I've only tested on 2022.
• My Details column does not mention how this relates to query performance, but the URL does.
• I wonder if we should add more columns to the statistics part of the sp_BlitzIndex output that you get when you pass in a single table.
• We should think about what interesting things we can do by joining #Statistics and #IndexSanity. I currently have no ideas.

[BrentOzar]

Thanks for the pull request and the demo code! Looks good, works on my machine, merging into the dev branch, will be in the next release with credit to you in the release notes.