Repository navigation
FinOps: storage growth for a database with no history shows n/a instead of 0, in both apps - #4902
Merged
Merged
Conversation
…ad of 0, in both apps
… drill, and the daily rate uses the real elapsed days
…n/a, not 0, and growth sorts with unknowns last
erikdarlingdata
marked this pull request as ready for review
October 1, 2026 17:43
erikdarlingdata
added a commit
that referenced
this pull request
Oct 4, 2026
… its whole size (#5077) (#5080) Storage Growth now counts a table created during the window as growing by its whole size. The object drill compares each table's reserved size at the database's latest snapshot with its earliest snapshot in the window. The grid ranked a table with no earliest row as unknown growth and put it last, while the heatmap ranked it as zero, so the two panels could cut different top-N sets and a large new table could miss the list. All four queries (the summary and daily-series reads, in Darling's DarlingFinOpsStorageGrowthReader and in Lite) now use current - COALESCE(earliest, 0) and sort by growth_mb DESC NULLS LAST, schema, table. That covers the desktop grids and heatmaps in both apps, the web Storage Growth tab and get_finops storage_growth. A new table's percent stays n/a. This reverses part of #4902: a database with only one snapshot in the window still reads n/a, but a table created since the earliest snapshot now ranks by an earliest size of 0. The get_finops guide no longer says the heatmap's table set can differ from the grid's, and it names both null cases. The database level and get_table_index_sizes keep their own rules. A source pin checks that all four queries share the growth expression and order, and a live pin around the cut fails on the old SQL. The view's re-rank test now seeds a table of unknown size. Refs #5077
12 of 14 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What a user saw
What changed
StorageGrowthSql: growth iscurrent - pastwith noCOALESCE, so a missing past is NULL.collection_time < latest; the Viewer nulls a past at or after the latest), so a stale server reads n/a.growth_30d_mb DESC NULLS LAST, growth_7d_mb DESC NULLS LAST, database_name.StorageGrowthRow(Lite and Viewer):Growth7dMb,Growth30dMb,DailyGrowthRateMbandGrowthPct30daredecimal?, read as null.ObjectSizeGrowthRow'sGrowth30dMb,DailyGrowthRateMbandGrowthPct30daredecimal?in both apps, null when the table has no earlier sample. The drill's rate still divides by its window.TargetNullValue='n/a', keeping the format.Consumers
Changed: both grids, both readers, both SQL constants, the plan-shape live oracle. Left alone: the per-table drill and heatmap use a different row type (
ObjectSizeGrowthRow) and the MCP table-size tool already returns null for missing baselines. No MCP tool emits these per-database fields. No other code sorts or charts the four properties.Pins
StorageGrowthNoHistoryLiveTests): no-history, 7-day-only and full-history databases; a server last collected 20 days ago reads all null; a 12-day gap gives 120/12; the drill is null for a single snapshot and for a new table; the order.StorageGrowth_ADatabaseWithNoPastRowReadsGrowthAsUnknown_NotZero, plus the stale server, the gap and the order inAzureSiblingGrowthTests, and the null drill inIndexObjectStatsTests. The existing rate pins divide by the real days between their seeded snapshots (31 and 8), and pins that expected 0 now expect null.Assert.Nullgot 0.00). The stale-server, gap and drill pins came with their fix in one commit; each asserts null or the real-days value where the code before it gives 0.00 or growth/7.CHANGELOG
SECTION: Fixed
ENTRY: - Storage Growth shows n/a, not 0, when there is no history to compare ([#4902]) - A database with no size row 7 or 30 days back, a server whose collection stopped more than a window ago, and a table in the per-table drill with no earlier sample all showed 0 growth, rate and percent in both the Lite and Viewer grids; they now show n/a. The daily rate also divides by the real days between the two snapshots instead of 7 or 30. Shipped in v3.8.0.
REF: [#4902]: #4902