You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When we judge missing index benefit, we look at the 'magic benefit number' divided by days of uptime. This makes sense as long as the table has been there the whole time, but less sense if it was created more recently.
We collect create_date in #IndexSanity, which is where we grab missing index details from. To avoid grouping awkwardness, I'm just going to grab ISNULL(NULLIF(MAX(DATEDIFF(DAY, t.create_date, SYSDATETIME())), 0), 1) here, and then in WHERE clause, it will look like
WHERE ( @Mode = 4 AND (magic_benefit_number / CASE WHEN create_days < @DaysUptime THEN create_days ELSE @DaysUptime END) >= 100000 )
OR (magic_benefit_number / CASE WHEN create_days < @DaysUptime THEN create_days ELSE @DaysUptime END) >= 100000
The text was updated successfully, but these errors were encountered:
BlitzErik
changed the title
sp_BlitzIndex -- Make Days Uptime an input parameter
sp_BlitzIndex -- Take table creation date into missing index benefit calculation
Jun 16, 2017
There are a couple other places where this calculation lives. Right now, those two places (Table mode and Mode 3) only reference the #MissingIndexes temp table. Will need to think of a clever way to make this match across all outputs.
When we judge missing index benefit, we look at the 'magic benefit number' divided by days of uptime. This makes sense as long as the table has been there the whole time, but less sense if it was created more recently.
We collect
create_date
in #IndexSanity, which is where we grab missing index details from. To avoid grouping awkwardness, I'm just going to grabISNULL(NULLIF(MAX(DATEDIFF(DAY, t.create_date, SYSDATETIME())), 0), 1)
here, and then inWHERE
clause, it will look likeThe text was updated successfully, but these errors were encountered: