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 a message like this: 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, the timeout is set, then applied when the query runs longer than 15000 ms. The following system view query confirms that a specific query was moved to the long pool:

premdb=# select pool_id, run_ms from sys.log_query where query_id=3639753;
 pool_id |  run_ms   
---------+-----------
 long    | 97083.613
(1 row)