Query_execution

The query factory should fire query execution. It should first reconstruct filter tree according to the most cost-effective scenario (that have been determined during cost calculation). The query factory should then send an execution request through the root connector. This request should contain details of the algorithms that have been reported during cost calculation as being most cost-effective in terms of I/O calls.

On views and stored procedures, the filter tree plan and details of the execution request should be taken from values stored in the database.

When a view or stored procedure is used, the query factory should then send a recalculation request in order to calculate current cost using the stored scenario only. If there is more than 30% cost difference between stored cost and current recalculated cost, then the query factory should do a full cost recalculation (using all possible scenarios).

During direct SQL calls through the call level interface, or dynamic statement, the filter tree and execution request should be calculated just before the query will be executed.

When a filter receives an execution request, it should then broadcast request to its input connectors, and wait on record to proceed. It should then execute the operation according to the algorithm that is specified in the execution request. The filter should then send through the output connector any single record that has been calculated. Filter should actually use streaming, as specified in cost calculation result.

Execution algorithm depends on the filter. Each filter has several algorithms. The execution request should specify the algorithm to use. See filter reference for details.

Filter should stop execution when an error or EOF message has been received. The message should be forwarded to the output connector prior to stop.

See also

• [Query_factory]
• [Set_engine]