Constrained Physical Database Design - Automated Physical Database Design and Tuning - page 212

KEEP VALID: Values of a constraint marked KEEP VALID can go up or down
from C p to C . However, if C p satisfies the constraint and C does not,
we prune C .
The previously discussed annotations effectively change the search strategy
and can be very useful. At the same time, however, they require a nontrivial
understanding of the search space, its relationship with constraints, and even
internals of the framework itself.

11.2.3.3 Transformation Guidance

Suppose that we want an existing index good I to appear in the final config-
uration. We can achieve this with
FORIinC
WHERE name(I) = "goodI"
ASSERT count(I) = 1

An alternative, more direct approach to achieve the same goal for this common
scenario is

AVOID delete(I) WHERE name(I) = "goodI"

which ignores transformations that match the predicate. In general we can
write

AVOID transformations [WHERE predicate]
As a less trivial example, to avoid merging large indexes we can use the fol-
lowing fragment:
AVOID merge(I1,I2)
WHERE size(I1) ≥ 100M OR size(I2) ≥ 100M

As with other heuristic annotations discussed in this section, the usage of
these alternatives should be guided by special knowledge about the search
space and its impact on the input constraints.

11.2.3.4 Handling Constraint Priorities

By manipulating the pruning conditions, we can enable a prioritized way of
dealing with constraints. In this special modality, constraints are sorted in
the order in which they appear in the specification, and we must satisfy them
in such order. For concreteness, let the ordered constraints be

X 1 ,... ,X n ,

before
i

after
i

and suppose that we transform C before into C after . Let X and X

be the score of X i under C before and C after , respectively. We can implement

prioritized constraints by pruning C after whenever the following condition
holds:

after before

i

before
j

∃ i ≤ n : X > X and ∀ j < i : X = 0

i