1. Command Line Options

-c <target file>

Compile the query into a standalone binary. By default, the C++ code generator will be used with g++ to generate the binary. An alternate compiled target language (C++ or Scala) may be selected using the -l flag.

-l <language>

Compile the query into the specified target language (see below). The default language is C++. The use of this flag overrides any previous -l or -r.

-o <output file>

Redirect the compiler's output to the specified file. If used in conjunction with -c, the source code for the compiled binary will be directed to this file. By default, output is directed to stdout or discarded if -c is used.

-r

Run the query (queries) after code generation and compilation. If no target language is specified using the -l flag, the C++ code generator will be used.

-F <optimization>

Activate the specified optimization flag. These are documented below.

-O[123]

Set the optimization level to 1, 2, or 3 respectively. At optimization level 1, compilation is faster and generated code is (usually) easier to understand and follow. At optimization level 3, compilation is slower, but more efficient code is produced. Optimization level 2 is the default. Overrides any prior -O flags provided on the command line.

-d <depth>

Limit the compiler's maximum recursive depth. By default, DBToaster compiles queries with the depth set to infinity.

-n <name>

Name of the structures (classes, objects) generated by DBToaster (default: Query).

--batch

Generate incremental view maintenance code for batch updates.

-xbs <batch_size>

Form batches of a given size during program execution.

2. Supported Languages

Language	Argument	Output Format	Description
DBToaster Relational Calculus	calc	output	DBToaster's internal query representation. This is a direct translation of the input queries.
M3	m3	output	A map-maintenance messages program. This is the set of triggers (written in DBToaster Relational Calculus) that will incrementally maintain the input queries and all supporting datastructures.
C++	cpp	output/compiled	A C++ class implementing the queries.
Scala	scala	output/compiled	A Scala class implementing the queries.

3. Optimization Flags

These flags are passed to the DBToaster compiler with the -F flag. The -O1 and -O3 flags each activate a subset of these flags. -O2 is used by default (no optimization flags active).

HEURISTICS-PULL-OUT-VALUES

Prevent value terms (variables and comparisons) from being materialized inside maps. In certain cases (e.g., mddb/query2.sql), this option reduces the number of generated maps and speed-ups the compilation time at the expense of doing more computation at runtime.

EXPRESSIVE-TLQS

By default, each user-provided (top-level) query is materialized as a single map. If this flag is turned on, the compiler will materialize top-level queries as multiple maps (if it is more efficient to do so), and only combine them on request. For more complex queries (in particular nested aggregate, and AVG aggregate queries), this results in faster processing rates, and if fresh results are required less than once per update, a lower overall computational cost as well. However, because the final evaluation of the top-level query is not performed until a result is requested, access latencies are higher. This optimization is not activated by default at any optimization level.

IGNORE-DELETES

Do not generate code for deletion triggers. The resulting programs will be simpler, and sometimes have fewer datastructures, but will not support deletion events. This optimization is not activated by default at any optimization level.

HEURISTICS-ALWAYS-UPDATE

In some cases, it is more efficient to re-evaluate expressions from scratch than maintaining them with their deltas (for example, certain queries containing nested aggregates). Normally, the compiler's heuristics will make a best-effort guess on whether to re-evaluate or incrementally maintain the expression. If this flag is on, the compiler will incrementally maintain all expressions and never re-evaluate.

COMPILE-WITH-STATIC

Perform static linking on compiled binaries (e.g., invoke g++ with -static). The resulting binaries will be faster the first time they are run. This optimization is not activated by default at any optimization level.

AGGRESSIVE-FACTORIZE

When optimizing expressions in DBToaster relational calculus, perform factorization as aggressively as possible. For some queries, particularly those with nested subqueries, this can generate much more efficient code. However, it makes compilation slower on some queries. This optimization is automatically activated by -O3.

AGGRESSIVE-UNIFICATION

When optimizing expressions in DBToaster relational calculus, inline lifted variables wherever possible, even if the lift term cannot be eliminated entirely. This can produce substantially tighter code for queries with lots of constants, but slightly increases compilation time. This optimization is automatically activated by -O3.

COMPILE-WITHOUT-OPT

Request that the second-stage compiler disable any unnecessary optimizations (e.g., by default, g++ is invoked with -O3, but not if this flag is active). This optimization is automatically activated by -O1.

WEAK-EXPR-EQUIV

When testing for expression equivalence, perform only a naive structural comparison rather than a (at least quadratic, and potentially exponential) matching. This accelerates compilation, but may result in the creation of duplicate maps. This optimization is automatically activated by -O1.

CALC-NO-OPTIMIZE

Do not apply calculus optimizations that simplify delta expressions. This option prevents range restrictions from being propragated through expressions, which usually leads to significantly worse performance. The resulting code is close to what the naive recursive incremental algorithm would produce. This flag is not activated by default at any optimization level.

CALC-NO-DECOMPOSITION

Do not apply query decomposition when computing deltas. This option is not activated by default at any optimization level.

DUMB-LIFT-DELTAS

When computing the viewlet transform, use the delta rule for lifts precisely as described in the PODS10 paper. If this flag is not active, a postprocessing step is applied to lift deltas that range-restricts the resulting expression to only those tuples that are affected, as described in the VLDBJ paper. This optimization is automatically activated by -O1.