Summaries

A summary is a smaller copy of one table's numbers, kept at a coarser grain: order lines added up by day and category rather than read line by line. A report that would add up millions of rows reads a few thousand instead, and a block that took seconds draws in a blink.

A report reads a summary only when it gives exactly the same answer as the table. When it cannot, or when rows have landed since it was built, the report reads the table as before. So a summary never changes a number. At worst it is not used.

You keep summaries for a report that is slow. sanda works out which ones would help, shows you what they would cost, and builds them only when you agree.

Speed up a slow report

Only owners and admins can keep a summary, because each one costs compute to build and to keep current.

Working out the plan counts the rows each summary would hold, which reads its table once, about as long as one slow block takes. sanda proposes the fewest small summaries that answer the report's blocks. Blocks that need the same things share one summary, and blocks that need different ones get their own, because one summary by both would be as large as the finer of the two.

You can also ask sam to speed a report up. sam always asks before it keeps or drops a summary, whatever its mode. See sam actions and approvals.

How a summary is checked

Before any report reads a new summary, sanda asks every block it was made for both ways, from the table and from the summary, at the same moment, and compares every cell and the type of every column. Any difference and the summary is dropped again, with a sentence saying so. A block that takes longer than 2 minutes from the table cannot be checked, and the summary is not kept.

A summary must also add back up to its table's own totals when it is built, be at least 20 times smaller than the table, and hold no more than 1,000,000 rows. One that would not is not kept, and says so.

What a summary can answer

A summary keeps its numbers by keys and at most one date, never by labels. A summary by category keeps the category's key, and a report joins the category's name to it as the table would. So a category renamed this morning reads its new name at once, and the summary answers by anything about categories, not just the column it was made for.

A report reads a summary when all of these hold:

• Every column the block groups by is one the summary keeps, the date at a grain that fits (a summary by day answers by week, month, quarter and year; by month answers by quarter and year), or a column of a table reached through one of its keys.
• Every filter is on such a column, or is a date range whose ends fall on whole days, weeks or months in your reporting time zone, as the summary keeps them.
• Every number is one the summary keeps, defined the same way: sums, counts, smallest and largest values, and averages of whole numbers and decimals.

These stay with the table:

• a count of distinct values, which cannot be added up again from a summary;
• a sum or average of a floating-point column, whose total depends on the order rows are added in;
• a number measured on another table, or a share of a total;
• a block that reads two different dates, or lists rows rather than adding them up.

Summaries answer the same questions wherever they are asked: report blocks, a block's earlier period and trend, delivered reports, shared links, the reports portal, sam's questions, and the first page of an OData feed.

Kept current after every landing

When rows land in a table a summary reads, sanda builds the summary again: after a pull, a sync, a CSV upload, rows added to an intake table, or rows an agent loads. Only summaries whose tables changed are built again. Until a summary is rebuilt, reports read the table, so a block is slower for that while and never out of date.

Building runs on your warehouse's compute and is billed like any other query, and a summary's rows count toward your storage. At most two summaries are built at once across sanda, so a build may wait a minute for its turn. Builds wait while your workspace is suspended for its budget, or while the warehouse is over its limits. Reports read the table meanwhile.

If a report finds a summary out of date that no landing refreshed, sanda builds it again, at most once every 10 minutes for a warehouse.

When the semantic fluid changes

These happen at the next landing. Until then, a number whose definition changed is read from the table, and the rest of the summary still answers.

The Summaries tab

Go to Data · Modelling and open Summaries. Every member can read the list; only owners and admins can act on a summary.

Each summary shows its state:

Select one to see its Rows (and how much smaller than its table it is), Size, what it Keeps, when it was Last built and the compute that took, how many block reads it has Answered, and who made it. Blocks it answers lists the blocks it was checked against, with how long each took From the table and From the summary.

• Refresh now builds it again if anything it reads has changed, and leaves it alone if not.
• Rebuild builds it again now, whatever has changed.
• Drop removes it. Reports that read it read the table again, which is slower and gives the same answers.

Where you see them

• On a block: hover over a chart or table to see where its answer came from and how long it took: Answered from a summary · 41 ms, or From the table · 4.2 s.
• On the map: a table with summaries says so on its card, for example 2 summaries, linking to this tab. A summary is never a card of its own and never appears in sam's view of your tables.

Limits

• A table keeps at most 3 summaries, and a workspace at most 20. The card says which blocks stay with the table when a limit is reached.
• A summary must be at least 20 times smaller than its table, and hold no more than 1,000,000 rows.
• The sanda sample dataset is shared and read-only, so it keeps no summaries.
• A summary can only be kept over tables whose changes sanda can see, so one over a materialized view is not kept, and building it says why.