Precomputation and Materialization¶

Version: v4 · 2026-08-30 · History
Prime #: 1415
Origin domain: Computer Science & Software Engineering
Subdomain: computation and system design → Computer Science & Software Engineering
Aliases: Eager Materialization, Build Time Computation, Precompute for Use
Related primes: Trade-offs

Core Idea¶

Precomputation and materialization pay for an expensive derivation before anyone asks for it and keep the answer in a form that later requests can read directly. The move is not "compute faster" but "compute earlier, and keep what you computed." Two commitments constitute the pattern. The first is a genuine timing choice: the derivation could legitimately have run at request time, and the design deliberately runs it sooner. The second is a durable output: the result persists in a shape that satisfies demand without re-deriving it. Strip either and the pattern is gone. Work that could only ever have run early is a dependency, not a choice; work thrown away before use is rehearsal. ^[1]

What the arrangement buys is a change in the shape of the cost curve rather than a reduction in total work. A derivation whose expense scales with the difficulty of the question becomes a read whose expense scales only with the size of the answer. Response time stops varying with problem structure and starts behaving like a constant, and that collapse of variance is frequently worth more than the arithmetic saving that accompanies it. ^[1]

What the arrangement costs is a standing obligation that did not exist before. A derived result which outlives its inputs can be contradicted by them, so the moment an artifact persists, someone owes the work of noticing when the sources move and then either repairing the artifact or withdrawing it. That duty is not an implementation detail bolted on afterwards; it is the second half of the bargain, and most failures attributed to this pattern are failures to pay it. ^[2]

Structural Signature¶

Deferrable derivation → early execution → retained artifact → cheap read → freshness obligation. Each of the five roles is load-bearing, and the ordering matters: a derivation that could have waited, a decision to run it ahead of demand, an output held in directly usable form, a later request satisfied by reading instead of deriving, and a continuing duty to reconcile what is held against sources that can move. ^[1]

Recurring features:

A defensible earlier moment. A real window separates the moment the inputs become available from the moment the answer is wanted, and the design occupies its front edge.
Asymmetric access counts. The stored result is read many times for each time it is produced, or it is read under a deadline that the production step does not have to meet.
A form fitted to the question, not to the inputs. The artifact is shaped by the request it will satisfy, so it is normally a summary or rearrangement rather than a copy of its sources.
Relocation rather than elimination of cost. Aggregate work usually increases once building and maintenance are counted; what changes is where the work sits relative to the critical path.
A live dependency from artifact back to sources. The stored result names, implicitly or explicitly, the inputs whose change would falsify it; that edge converts a source update into an obligation.
Variance collapse on the read path. Worst case and typical case converge, which is why the pattern is chosen as often for predictability as for average speed.
An admitted discard path. Every genuine instance has some way of conceding that the artifact is wrong — rebuild, expiry, version bump, recall, or scrap — and instances that lack one are not stable designs.

What It Is Not¶

This is not a general endorsement of planning ahead, and not every early effort belongs here. Preparing thoroughly, starting a project sooner, or front-loading a schedule are all ways of doing work earlier, but none of them necessarily produces a retained result that later demand consumes without redoing the work. The test is narrow: after the early effort, is there an object that answers the question, and does answering by reading it genuinely displace the derivation it replaced?

Nor is the pattern a claim that speed is good. It is a placement decision, and placement decisions can be wrong in either direction: right when demand is likely, repeated, or deadline-bound, and wrong when demand is speculative, sources churn faster than the artifact can be maintained, or the derivation was never the bottleneck. Naming the pattern does not recommend it.

It is also not the same as keeping data. Filing away inputs so they can be processed later is storage, and it leaves the expensive step exactly where it was. Materialization stores a conclusion. That distinction is what makes the freshness obligation appear at all: raw inputs cannot go stale against themselves, whereas a conclusion can be quietly contradicted by the very things it was drawn from.

Finally, the pattern is not confined to machines, and it is not defeated by the fact that total effort usually rises. A workshop that cuts and finishes components before an assembly date, a reference table computed once and consulted for decades, and a clinic that assembles procedure trays in advance are all instances. In each case somebody accepted more total work, plus a duty to keep the stored thing honest, in exchange for a cheap and predictable moment of use.

Broad Use¶

In computing and data systems the pattern is nearly ubiquitous: materialized views and summary tables, compiled binaries and build artifacts, search indexes rebuilt on a schedule, statically rendered pages, precomputed embeddings, and the trained weights of a model, which are nothing but an enormously expensive derivation retained so that inference becomes a comparatively cheap read. ^[1]

In mathematics, engineering, and graphics it appears as tabulation: logarithm and trigonometric tables that made centuries of hand calculation tractable, ballistic and tide tables, precomputed meshes for finite-element analysis, and baked lighting in rendered scenes, where hours of light-transport simulation are frozen into textures so that each displayed frame only has to look the answer up.

In manufacturing and construction it is prefabrication. Precast panels, factory-built modules, cut-to-length kits, and pre-kitted component trays move assembly work off the constrained site and into a controlled shop, leaving the site with connection work rather than fabrication work. Kitchens do the same thing under a different name when they prepare components in advance of service.

In biology and medicine the roles recur without any designer. An organism holding a stock of pre-synthesised enzyme, or an immune system retaining memory cells after a first exposure, has converted a slow derivation into a fast response, and each carries a freshness liability when the substrate or the antigen changes. Clinically, prepared reagents, cross-matched blood units, and sterilised instrument sets are held ready and carry expiry.

In records, administration, and commerce the pattern is old and formal. Catalog headings, back-of-book indexes, mortality and tax tables, standard form contracts, tariff schedules, and pre-picked warehouse orders all encode a determination made in advance so a later query becomes a lookup. The recurrence of the same five roles across mechanical, biological, and institutional media is what makes this a prime rather than a computing technique.

Clarity¶

The confusion this prime dissolves is the equation of a fast system with a system that is doing little work. Once the pattern is named, the observation "this responds instantly" stops being a statement about efficiency and becomes a question about accounting: something earlier absorbed the expense, and until that build step and its maintenance are on the ledger, no one has actually measured anything. Comparisons between systems that answer in a millisecond and systems that answer in a second are usually comparing placement, not capability. ^[3]

A second confusion it clears up concerns the nature of the errors such systems produce. Without the pattern, a wrong answer suggests that the logic is wrong and invites debugging the read path. With the pattern in view, a distinct and much more common failure becomes visible: the logic was right, the answer was correct at the moment it was derived, and the inputs have since moved. "Incorrect" and "no longer current" call for entirely different repairs, and conflating them sends investigation in exactly the wrong direction. ^[4]

Third, it converts staleness from an embarrassment into a specification. Once the artifact is understood as a snapshot, the design question is not whether the answer can be out of date but by how much, and who is entitled to know. Systems that decline to state a bound have not avoided staleness, only left it undocumented.

Manages Complexity¶

What the pattern lets you stop tracking is the derivation itself. Before materialization, every consumer of an answer must in principle understand how it is produced: which sources feed it, how they are joined, which edge cases the combination has, how expensive it is under load, and what happens when one input is slow or missing. Afterwards, consumers face a single object and a single statement about how current it is. Many partially understood dependencies collapse into one explicit one.

That collapse has a second effect worth naming separately. When several consumers each derive the same answer independently, they will eventually disagree, because their versions of the logic drift apart at different rates. Materializing the derivation once makes disagreement structurally impossible for everyone downstream of the artifact: they may all be stale together, but they cannot be inconsistent with each other. Shared staleness is a far easier condition to reason about than distributed divergence.

Capacity planning simplifies for the same reason. A read path whose cost depends only on the size of the result is easier to size and budget than a derivation whose cost depends on the shape of each incoming question.^[5] The concentrated cost is not free; it moves into a build window that must itself be scheduled and provisioned. But it moves into one place, at a time of the designer's choosing, where it can be watched. ^[6]

Abstract Reasoning¶

The prime licenses a compact diagnostic. Faced with a system that answers a hard question suspiciously cheaply, ask three things in order. Where did the work go, and what is the build step that paid for it? What is the artifact's dependency set, and what event is supposed to trigger its repair? And what is the largest age at which this answer is still fit for its purpose, compared with the interval at which repair actually occurs? A system that cannot answer the third question has an unbounded staleness exposure regardless of how well the first two are engineered.

It also supplies a clean classification test in the form of a counterfactual. Delete the stored artifact and ask what happens. If the system still produces the answer, only more slowly and more expensively, the artifact was a materialization and the prime applies. If the answer becomes unobtainable, the artifact was not a retained derivation at all but the system's source of truth, and something else is going on — the derivation you imagined was upstream either never existed or has been discarded. That single question separates most genuine instances from the superficially similar ones.

The pattern further predicts a characteristic failure mode, which is silence. Errors here do not announce themselves with exceptions or malformed output; they arrive as well-formed, internally consistent, confidently delivered answers describing a state of the world that has passed. The useful test is therefore never an inspection of the read path, which will look perfect, but a comparison between the artifact and a freshly executed derivation — which is why any serious deployment keeps the slow path alive as an oracle.

Knowledge Transfer¶

The five roles carry across substrates, and so does the reasoning built on them — a transfer this entry argues on structural grounds rather than one any cited source establishes. Whether the medium is a database, a factory yard, a reference volume, or a cell, one can ask what could have been derived later, what was derived early instead, what is being held, what reads it, and what happens when the sources move. The cost-relocation logic travels too: in the database case, where it is documented, speed on the read path is bought with space,^[5] and with the continuing maintenance a stored derivation needs as its sources change. ^[4]

What does not travel is the economics of repair, and this is where cross-domain reasoning most often goes wrong. In software, discovering that an artifact is stale is close to costless: discard it and rebuild, paying only the build cost again. In physical media the same discovery can be ruinous. A precast panel cut to a superseded drawing is scrap with storage, transport, and disposal costs attached; a pre-mixed reagent past its window is regulated waste; a printed edition of a table is a recall problem. Anyone importing intuitions about aggressive rebuilding from a domain with cheap discard into one with expensive discard will systematically over-materialize.

Two further properties are substrate-specific and must be re-derived rather than assumed. The first is whether partial repair exists: some artifacts can be patched in proportion to the change, others are all-or-nothing. The second is whether staleness is visible. A digital artifact can carry a version stamp checkable in constant time, whereas a prepared tray or a stocked component looks identical whether or not the specification behind it has moved — which is why physical instances lean so heavily on dating, labelling, and freeze discipline. Transfer the roles and the trade; recompute the refresh economics locally.

Examples¶

Formal/abstract¶

Consider an array of n numbers subject to many range-sum queries, each asking for the total of the elements between two positions. Answering directly costs work proportional to the width of the range, so a workload of wide queries becomes expensive in a way that depends on which questions arrive. The precomputed alternative makes a single pass and stores a prefix table, in which entry i holds the sum of everything up to position i. Any range sum then becomes the difference of two stored entries: two reads and a subtraction, with a cost that does not depend on how wide the range is. The build costs one pass and n+1 stored numbers; the query cost stops varying with the question entirely. ^[7]

The obligation arrives with the first write. Changing a single element invalidates every prefix entry beyond it, so an update that is trivially cheap against the raw array requires repair work proportional to the length of the table. The asymmetry is the design problem: read-dominated workloads make the trade overwhelmingly favourable, while frequent writes make maintenance exceed everything the queries saved. Locating that crossover, not admiring the constant-time query, is the engineering task. The well-known refinement that stores partial sums in a tree rather than a flat table makes each query slightly more expensive in exchange for making each repair logarithmic instead of linear.

Mapped back: every role is present and identifiable. The derivation is deferrable, since each sum could be computed on demand. Execution is moved early, into one pass before any query arrives. The retained artifact is the prefix table, shaped by the question it answers rather than mirroring the data it came from. The read is cheap and, more importantly, invariant. And the freshness obligation is explicit, with a repair cost wildly out of proportion to the change that triggered it. The tree-based refinement demonstrates that the balance between read cheapness and repair cost is a dial the designer sets, not a fixed property of the pattern.

Applied/industry¶

High-rise residential construction increasingly uses prefabricated bathroom pods: complete bathroom modules built in a factory, tiled, plumbed, wired, and fitted out, then delivered and craned into position as the structure rises. On site, several weeks of sequenced trade work per unit — waterproofing and its cure, tiling, fixture installation, inspection — collapse into a lift and a set of connections at the floor slab. The assembly could have been performed in place at the moment each floor was ready; the design instead performs it months earlier in a controlled shop and holds the finished units in a yard. ^[8]

The payoff has the familiar shape. The site programme is decoupled from trade-crew availability and from weather, which is where most of its variance came from, and quality variance falls because one jig, one crew, and one inspection regime are applied repeatedly at bench height. The critical path shortens by a predictable amount, so the schedule can be committed with more confidence.

The obligation is equally familiar and considerably more expensive. Pods are built against a fixed drawing set, so a relocated service riser, a revised accessibility standard, or a client's late fixture substitution invalidates every unit already built to the superseded specification. Unlike a stale summary table, they cannot be rebuilt for the price of a rebuild: they are physical scrap carrying storage, transport, and disposal costs. Projects that adopt pods therefore impose a discipline that conventional construction does not require, freezing the relevant design earlier and pricing late variation against the value of materialized inventory rather than against the cost of amending a drawing.

Mapped back: the same five roles appear with the same ordering, and the interesting content of the comparison lies entirely in the last one. Deferrable derivation, early execution, retained artifact, and cheap read are structurally identical to the prefix-table case; what differs is that repair is neither cheap nor incremental nor easy to detect, since a pod built to an old drawing looks exactly like a pod built to the current one. That is why the physical instance answers the maintenance problem with a governance mechanism — an earlier design freeze and a change-order gate — where the computational instance answers it with a data structure. The prime is the same; the refresh economics are not. ^[9]

Structural Tensions¶

T1 — Staleness is the price, not the defect. Every retained answer is a snapshot of sources that keep moving, so the pattern does not choose between fresh and stale but between a bounded staleness that is stated and an unbounded staleness that is not. Teams treat a stale result as a bug to eliminate rather than a quantity to specify, then find that eliminating it means refreshing continuously — the derivation they were avoiding. The honest form of the design states a maximum age and defends it; the dishonest form promises currency it never had.

T2 — Precomputing for demand that never arrives. The pattern pays in advance for questions that may not be asked, and the temptation is always to cover more of the possible question space. Coverage grows combinatorially while real demand concentrates on a small fraction, so materializing every combination burns build capacity and storage on results nobody reads, and the waste stays invisible because unread artifacts do not complain. Narrow coverage, meanwhile, means the expensive derivation still runs for the cases outside it, often at the worst possible moment.

T3 — Invalidation is harder than computation. Producing the artifact is a self-contained problem with a definite answer; knowing precisely when it has become wrong requires tracking every path by which any source can change, including paths added later by people who have never heard of the artifact. Dependency sets are chronically under-specified, so the choice is between conservative over-refreshing, which forfeits much of the saving, and precise invalidation, a distributed correctness problem harder than the derivation it protects.

T4 — The frozen assumption. Materialization does not merely store a result; it stores the assumptions in force when the result was derived, including assumptions nobody wrote down. A table computed under one definition of a business metric, one tax rule, or one standard keeps answering confidently after the definition changes, because nothing in the artifact records what it presupposed. The longer an artifact survives, the likelier its embedded assumptions have quietly expired, and the harder they are to find, because the derivation holding them no longer runs.

T5 — The artifact hardens into the interface. Once consumers read a materialized result directly, its shape becomes a contract that was never negotiated. Changing the derivation now means migrating everyone bound to the old form, so the very stability that made the pattern valuable makes the underlying logic progressively unchangeable. What began as a performance decision ends as an architectural commitment, and organizations keep derivations they no longer believe in because reshaping the artifact costs more than tolerating its answer.

T6 — The fast path makes the slow path pathological. After materialization, performance becomes bimodal: reads are cheap and uniform, and anything falling outside the artifact is served by a derivation that is now rare, unexercised, and unprovisioned. Capacity is planned for the fast path and monitoring watches it, while the slow path decays through disuse until a rebuild window, a coverage gap, or a mass invalidation forces traffic onto it at once. Systems shaped this way fail rarely and then completely.

Structural–Framed Character¶

Precomputation and Materialization sits at the structural end of the structural–framed spectrum, graded structural with an aggregate of 0.00 and every criterion at zero. The relation is a timing choice with an artifact in it: work that could occur before or after demand, a design that chooses the earlier time, a result stored in usable form, later requests that avoid recomputation, and a refresh obligation whenever source inputs change. The early artifact is part of the mechanism, not incidental residue.

The criterion doing the most work is vocabulary, and it reads zero because the terms can be made medium-neutral without losing the mechanism. Early work, a retained artifact, cheap use, and a refresh obligation describe a materialized view, a compiled program, a lookup table, a prefabricated assembly, and a prepared reagent equally well, without any one lexicon.

Evaluative weight reads zero: the prime names a trade rather than a recommendation, shifting cost from use time onto build, storage, refresh, and possible staleness, with lazy evaluation standing as the opposing demand-triggered choice rather than the inferior one. Institutional origin reads zero — prefabricated assemblies and prepared reagents carry the roles with no computing practice present — and human-practice-bound reads zero, since none of the four roles names an agent. Import-vs-recognize is recognition.

A clean structural grade means the prime applies wherever the timing choice and the retained artifact are both real, and the near neighbours mark where it does not: caching requires a fast local copy, locality, and a replacement policy; denormalization requires controlled redundancy against a canonical form.

Substrate Independence¶

Precomputation and Materialization is a highly substrate-independent prime — composite 4 / 5 on the substrate-independence scale. Five medium-free roles carry it: a derivation that could legitimately have waited, a decision to run it ahead of demand, an artifact retained in a directly usable shape, a later request satisfied by reading rather than deriving, and a standing duty to reconcile that artifact against sources which can move. Materialized views, compiled binaries, lookup tables, prefabricated building assemblies, catalog subject headings, and reagents prepared before the bench calls for them all fill those roles. What holds it below the ceiling is where the convincing instances gather: settings that actually meter derivation cost, read cost and staleness, while elsewhere the same bargain is asserted rather than shown.

Composite substrate independence — 4 / 5
Domain breadth — 4 / 5
Structural abstraction — 4 / 5
Transfer evidence — 4 / 5

Relationships to Other Abstractions¶

Current abstraction Precomputation and Materialization Prime

Parents (1) — more general patterns this builds on

Precomputation and Materialization presupposes Trade-offs Prime

Eager materialization exists only as a balance between build, storage, refresh, and staleness costs and cheaper, more predictable use-time access.

Children (1) — more specific cases that build on this

Precoordinated Heading Domain-specific is a decomposition of Precomputation and Materialization

Removing subject-vocabulary machinery leaves eager combination before demand, a retained directly matchable artifact, and an update obligation.

Hierarchy path (1) — routes to 1 parentless root

Precomputation and Materialization → Trade-offs → Constraint

Neighborhood in Abstraction Space¶

Precomputation and Materialization sits in a sparse region of abstraction space (71^st percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely rather than landing on a neighbor.

Family — Data Integrity & Provenance Infrastructure (7 primes)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-10

Not to Be Confused With¶

Precomputation and Materialization must first be distinguished from Caching, the neighbour it is most often collapsed into. Caching stores results for faster retrieval and shares the retained-artifact role, but adds three commitments this prime does not require: it is populated reactively by observed demand, it presupposes locality of reference, and it runs under capacity pressure with a replacement policy deciding what to evict. Materialization is populated on a schedule or build trigger regardless of whether anyone has asked, holds what the designer chose, and usually has no eviction policy because nothing competes for the space. A cold cache is normal and self-correcting; a cold materialized artifact means the build did not run, which is an incident. The practical test is whether the first request for an item is expensive: in caching it is, in materialization it is not.

The pattern stands opposite Lazy Evaluation, which defers work until its result is actually demanded. The two occupy the same axis at its two ends, and they answer the same question with opposite policies. Lazy evaluation wins when much of the potential work is never needed, when inputs change faster than results are consumed, and when being wrong about demand is costly; eager materialization wins when demand is near-certain, repeated, or deadline-bound. Neither is a degenerate case of the other, and most systems contain both, with the real design work at the boundary between them.

An Index is a close relative that is nonetheless a narrower thing. An index is an auxiliary key-to-location structure that accelerates lookup while leaving the underlying answer to be assembled from the located records. Materialization stores the answer itself, not directions to the material from which the answer would be built. The difference shows up in what each removes: an index removes search, whereas materialization removes derivation. A system can have a perfect index and still pay the full cost of a complex aggregation, because finding the rows was never the expensive part.

Denormalization overlaps but is defined by a different commitment: controlled redundancy against a canonical form, accepted in exchange for access-side wins. Its defining relation holds between a copy and an authoritative original, and its liability is divergence between duplicates of one fact. Materialization's stored object is usually not a copy at all but a derived result with no canonical counterpart, and its liability is obsolescence. Many designs are both at once, which is why the roles need separating: they fail and are repaired differently.

Batch Processing collects discrete work items so a costly setup is paid once and amortised over the group. Both do work ahead of the moment it might otherwise be done, but batching is a grouping decision aimed at setup cost and need not retain anything afterwards: a batch job that computes and immediately dispatches results has amortised setup without materializing anything. Conversely a materialization can be built one item at a time with no grouping economy at all. They travel together often, but the retained artifact, not the grouping, is what makes it this prime.

Buffering maintains an intermediate capacity that absorbs excess and releases it during shortfall, decoupling a source from a consumer whose rates do not match. Both hold something between production and consumption, but a buffer holds units that pass through unchanged, and its purpose is rate reconciliation. Materialization holds a transformed result, and its purpose is to remove a computation from the consumer's path. A buffer that is never drained is a failure; an artifact that is read a thousand times without depleting is working exactly as intended.

Finally, Preparation holds a system in a primed state nearer its activation threshold, paying a standing cost for a faster or larger response when the trigger comes. This is genuinely adjacent, and the two often co-occur, but preparation raises readiness without necessarily producing a specific answer to a specific question. A crew on standby is prepared; a stack of finished components is materialized. The distinguishing question is whether what is held would satisfy a request by itself, or merely shorten the work of satisfying it. Postponement, which delays commitment until a resolving signal arrives, is the direct policy opposite of that commitment, and Trade-offs is the parent relation under which the whole timing decision is priced.

Solution Archetypes¶

No catalogued solution archetypes reference this prime yet.

Notes¶

The pattern's difficulty concentrates almost entirely in one of its five roles. Building the artifact is a bounded engineering problem; knowing when it has gone wrong is an open-ended one, because the dependency set grows every time somebody adds a new way for a source to change. A useful heuristic is to estimate the refresh mechanism's effort before the build's, and to treat any design that has not named its invalidation trigger as incomplete.

Scale moves the answer. At small scale the derivation is cheap and the artifact is pure overhead; at very large scale the build may exceed any available refresh window, forcing partial or hierarchical materialization. The band in which the pattern is clearly right shifts whenever storage costs, compute costs, or change rates shift, so designs correct when adopted deserve re-examination rather than defence.

A governance dimension is worth flagging. Because a materialized result is consumed without its derivation being visible, the reasoning that produced it stops being reviewed. Over long periods this is how institutional artifacts outlive the assumptions that justified them.

References¶

[1] Gupta, Ashish, and Inderpal Singh Mumick, eds. Materialized Views: Techniques, Implementations, and Applications. MIT Press, 1999. Collects the literature defining a materialized view as a query result computed ahead of demand and stored, so that later access is a read rather than a derivation, at the price of a standing maintenance obligation. registry ↩a ↩b ↩c ↩d

[2] Blakeley, Jose A., Per-Ake Larson, and Frank Wm. Tompa. "Efficiently Updating Materialized Views". Proceedings of the 1986 ACM SIGMOD International Conference on Management of Data, 1986. Establishes that a stored derived result must be reconciled when its base data change, and develops the machinery for detecting which updates matter and applying the repair. registry ↩

[3] Tarjan, Robert Endre. "Amortized Computational Complexity". SIAM Journal on Algebraic and Discrete Methods 6, no. 2, 1985. Formalises the accounting view in which a cheap observed operation is paid for by expense charged elsewhere in the sequence, so the cost of a single fast operation is not by itself a measure of work done. registry ↩

[4] Chirkova, Rada, and Jun Yang. "Materialized Views". Foundations and Trends in Databases 4, no. 4, 2011. States that a materialized view's stored contents go out of date as soon as its base tables change and must be repaired by incremental maintenance or recomputation, a failure of currency distinct from a wrong query. registry ↩a ↩b

[5] Harinarayan, Venky, Anand Rajaraman, and Jeffrey D. Ullman. "Implementing Data Cubes Efficiently." ACM SIGMOD Record, vol. 25, no. 2 (1996): 205–216. Supports the cost model only: for a materialized result "the cost of answering Q is the number of rows present in the table for that query," so read cost tracks the size of what is scanned rather than the shape of the question, and read speed is bought with space, since "precomputing and storing every cell is not a feasible alternative for large data cubes, as the space consumed becomes excessive." It says nothing about budgeting practice or service guarantees, and nothing about substrates other than databases. registry ↩a ↩b

[6] Colby, Latha S., Timothy Griffin, Leonid Libkin, Inderpal Singh Mumick, and Howard Trickey. "Algorithms for Deferred View Maintenance." SIGMOD '96 (1996): 469–480. Supports that the derivation cost can be lifted out of the update path and run in a window the designer picks: "deferred maintenance may be done periodically or on-demand when certain conditions arise." It does not support the further claim that cost so concentrated is thereby easier to watch; that inference is this entry's own. registry ↩

[7] Crow, Franklin C. "Summed-Area Tables for Texture Mapping". Proceedings of the 11^th Annual Conference on Computer Graphics and Interactive Techniques (SIGGRAPH '84), 1984. Precomputes a table whose entries hold the running integral of the source data, so the total over an arbitrary region is recovered by adding and subtracting a fixed number of stored entries at a cost independent of the region's extent. registry ↩

[8] Kim, Sunai. "Prefabricated and Modularized Residential Construction: A Review of Present Status, Opportunities, and Future Challenges". Buildings 15, no. 16, 2025. Reviews modular bathroom pods assembled in a factory and later installed into high-rise residential buildings, reporting time and cost savings and improved quality control as the effects of moving the work off site. registry ↩

[9] UK Ministry of Housing, Communities and Local Government. Volumetric Modular Construction Research. Ministry of Housing, Communities and Local Government, 2024. Names early design freeze as a critical success factor for volumetric construction, reports late decisions as a leading cause of programme delay, and notes that defects built in at the point of manufacture are replicated across all units. registry ↩