Expected selected buckets
4.52
of 20
LESS SCANNING. MORE CLARITY.
Plan your
DSAR footprint.
Find a bucket count. Compare the trade-offs.
See what the model predicts, and what your SQL actually shows.
EXPECTED BUCKET COVERAGEModel
22.62%
20 buckets · 5 unique accounts
Calculation inputs
days
11 billion
01 million
01 trillion
1 MiB1 PiB
Examples
10,000 micro-partitions and 100 GiB are example inputs, not measurements.
All period estimates use the same unique ID list and hash expression on every day.
Estimated footprint
Micro-partitions · ideal
2,262
of 10,000
Data scanned · ideal
22.62 GiB
of 100 GiB
Scan reduction · ideal
4.42×
Relative to the same unpruned period
Buckets identify where to look. Some requested IDs may have no events in the selected period. These values do not predict UPDATE duration.
Find a bucket count
Keep expected coverage at or below your target, for the current unique account count.
%
48
Use an observed SQL result
Enter the occupied candidate bucket count from SQL over your request IDs, using the same ID type and bucket expression.
—
—
Physical scan estimates remain idealized, even with observed logical coverage.
Compare scenarios
Pin a baseline, then change the inputs to explore scenario B.
No baseline pinned yet. Your current inputs become scenario A when you pin them.
| Metric | A · pinned | B · current | B − A |
|---|
More accounts, wider coverage
What if you change the buckets?
These rows always show the model, including when observed coverage is applied above.
Collisions, made visible
One independent, uniform random assignment of the current IDs. This is an illustration, not Snowflake HASH and not a measurement.
4.52
—
—
Empty1 ID2+ IDs
How the model works
f(x, y) = 1 − (1 − 1/x)yMinimum buckets for target t:ceil(1 / (1 − (1 − t)1/y))
For y = 0, coverage is 0. For x = 1 and y > 0, coverage is 100%.
Distinct account IDs are assumed to map independently and uniformly to x buckets. f is both the chance that a preselected bucket is occupied and the expected fraction of occupied buckets. Collisions are expected: multiple IDs can share a bucket.
Expected occupied buckets: x × f. Ideal partitions: P_period × f. Ideal data: D_period × f. Ideal scan reduction: 1 / f, relative to the same period without bucket pruning. Zero coverage has no finite reduction factor.
Daily-average inputs are multiplied by the number of days; entire-period inputs are used once. Daily partition totals assume day-disjoint micro-partitions. Multi-day estimates require the same account list and bucket expression each day, comparable layouts and good date grouping. They do not model which IDs have events on each day.
Observed mode replaces f with occupied_buckets / x for the main footprint and scenario comparison. The target solver and account-growth chart remain model-based. SQL over the request list measures candidate buckets. Counts over matching event rows answer a different question and must not be substituted for request-list counts. Neither measures physical partitions read.
The SQL below is a template. Replace its source and ID column, and match the events table's identifier type and exact clustering expression. The browser does not implement Snowflake HASH.