This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
admin:optimization:config:optimizations [2012/02/07 23:57] doc |
admin:optimization:config:optimizations [2016/06/28 22:38] (current) |
||
|---|---|---|---|
| Line 53: | Line 53: | ||
| === REQUIRED_OPTIMIZATION === | === REQUIRED_OPTIMIZATION === | ||
| + | |||
| + | The REQUIRED_OPTIMIZATION setting instructs Omnidex to insure that the named optimizations will be performed for a query. If a REQUIRED_OPTIMIZATION setting cannot be performed, then the query will return an error condition. This setting can be set using an option on the SELECT statement: | ||
| + | |||
| + | <code> | ||
| + | select ... with REQUIRED_OPTIMIZATION='setting1,setting2,setting3,...' | ||
| + | </code> | ||
| + | |||
| + | The REQUIRED_OPTIMIZATIONS settings are shown in the table below: | ||
| + | |||
| + | ^ Setting ^ Description ^ | ||
| + | | NO_XREF_FILES | Do not create Cross-Reference files when processing this query. Cross-Reference files are sometimes used to optimize complex, many-to-many table relationships, but they generally cause a query to take a lot of time, especially on large databases. | | ||
| + | | NO_UNOPTIMIZED_CRITERIA | Do not allow any criteria to be processed without the use of Omnidex indexing. | | ||
| + | | NO_CARTESIAN_PRODUCTS | Do not allow Cartesian Joins. Cartesian Joins occur when tables are joined together without any join criteria. While there are rare cases when Cartesian Joins are desireable, they are usually an indication of missing join criteria. | | ||
| + | | NO_UNOPTIMIZED_AGGREGATIONS | Do not allow any aggregations to be processed without the use of Omnidex indexing. | | ||
| + | | NO_UNOPTIMIZED_SORTS | Do not allow any sorts to be processed without the use of Omnidex indexing. | | ||
| + | | NO_SEQUENTIAL_SCANS | Do not allow any sequential table scans. | | ||
| + | | NO_SEQUENTIAL_TABLE_JOINS | Do not allow any sequential table joins. A sequential table join indicates that all rows in the second table will be scanned sequentially for each row in the first table. This is the most inefficient way to perform a join, and is only necessary when Omnidex indexing, underlying database indexing, table caching and sort/merging cannot be used. | | ||
| + | | NO_GRID_AGGREGATIONS | Do not allow any aggregations to be performed on the grid controller that require reaggregating data on the grid controller. | | ||
| + | |||
| ===== ===== | ===== ===== | ||
| ---- | ---- | ||
| \\ | \\ | ||
| - | **[[admin:optimization:config:optimizations|Next]]** | + | **[[admin:optimization:config:home|Prev]]** | |
| + | **[[admin:optimization:config:thresholds|Next]]** | ||