Compile Rule Examples

The following examples show rules that are evaluated as queries enter the compile state.

Throttle Users at Compile Time

This compile rule is called compile_throttle_users, and it is designed to make sure that a set of users cannot use up compile-time resources at the expense of other queries and sessions. The condition in this example applies to users with backup in their names (such as backup1 and backup2). As queries submitted by these users enter the compile state, concurrency is limited to 1, preventing them from running multiple queries concurrently.
Rule Preview:
if ((String(w.user).indexOf('backup') >= 0)) {
	wlm.throttle(1, w.user);
}

When this rule is applied, the administrator sees:



Note the following message: Throttle 1 accesses for barrier backup2. In this case, the "barrier" to concurrency is the user backup2.

Move a Query to the "Long" Pool

The flexMoveToLong rule is a predefined Compile rule for the flex profile:
setTimeout(function () {
  log.info('Moving long-running query to resource pool "long": {}', w.execId);
  if (w.resourcePool !== 'long' && w.movable) {
    w.moveToResourcePool('long');
  }
}, 15*1000);

This rule sets a timeout of 15000 ms for the run_ms statistic, which is clocked when the query starts running. If run_ms exceeds 15000, the query is moved to the long resource pool (assuming that the query is not already running in the long pool and is movable; not all types of queries are movable). This rule is evaluated as a compile rule but affects runtime processing because of the timeout delay.

When this rule is applied and a query is moved, the administrator sees:



Note that the timeout is set, then applied when the query runs longer than 15000 ms. The following system view query confirms what happened:
premdb=# select pool_id, run_ms from sys.log_query where query_id=3639753;
 pool_id |  run_ms   
---------+-----------
 long    | 97083.613
(1 row)