Database Reference
In-Depth Information
Aggregation: Generators allow us to duplicate a constraint multiple
times by replacing a free variable in the ASSERT clause with a range
of values given by the generator. In many situations, we want a con-
straint acting on an aggregate value calculated over the elements in a
generator. As a simple example, we can rewrite the original storage con-
straint used in physical design tools using generators and aggregates as
follows:
FORIinC
ASSERT sum(size(I)) 200M
As a more complex example, the following constraint ensures that the
combined size of all indexes defined over table T is not larger than four
times the size of the table itself:
FORIinC
WHERE table(I) = TABLES["T"]
ASSERT sum(size(I))
4 * size(TABLES["T"])
where TABLES is the collection of all the tables in the database, and
function size on a table returns the size of its primary index.
Nested constraints: Constraints can have free variables that are bound
by outer generators, effectively resulting in nested constraints. The net
effect of the outer generator is to duplicate the inner constraint by bind-
ing each generated value to the free variable in the inner constraint. The
following constraint generalizes the previous one over all tables:
FOR T in TABLES
FORIinC
WHERE table(I) = T
ASSERT sum(size(I)) 4 * size(T)
Soft constraints: The implicit meaning of the language defined so far is
that a configuration has to satisfy all constraints to be valid. Among
those valid configurations, we keep the one with the minimum expected
cost for the input workload. There are situations, however, in which
we would prefer a relaxed notion of constraint. For instance, consider a
constraint that enforces that every non- UPDATE query results in at least
10% improvement over the currently deployed configuration. In general,
no configuration may satisfy this constraint, especially in conjunction
with a storage constraint. In these situations, a better alternative is
to specify a soft constraint , which states that the final configuration
should get as close as possible to a 10% improvement (a configuration
with, say, 8% improvement would still be considered valid). We specify
Search WWH ::




Custom Search