This is an old revision of the document!


Administration: Optimizing Queries

Query Plans

Configuring Query Plans

Omnidex Query Plans have some configuration options that will increase the amount of information available. These are available using the SET EXPLAIN command in OdxSQL. The syntax of the SET EXPLAIN command is:

SET EXPLAIN [COUNTS] [TEXT] [NODES]
COUNTS

The COUNTS option will cause the explain to display row counts when known, and timings for certain steps. This option only effects query plans that are run after the query has completed. This is done by issuing the SELECT statement, letting it complete, and then typing the command “EXPLAIN” by itself.

Counts and timings can be quite useful toward determine where query performance is most affected. The follow query plan shows the counts and timings for a well-optimized query:

> set explain counts
> explain
----------------------------------- SUMMARY -----------------------------------
Select        I.GENDER,
              count(*)
  from        HOUSEHOLDS H
  join        INDIVIDUALS I on H.HOUSEHOLD = I.HOUSEHOLD
  where       ((H.STATE = 'CO' and
                H.CITY = 'DENVER') or
               (H.STATE = 'AZ' and
                H.CITY = 'PHOENIX')) and
              I.BIRTHDATE > 'January 1, 1980'
  group by    I.GENDER;

Version:      5.2.01  (Compiled Feb  2 2012 21:29:57)
----------------------------------- DETAILS -----------------------------------
Qualify (HOUSEHOLDS)HOUSEHOLDS where CITY = 'DENVER';
   (15 HOUSEHOLDS, 15 Pre-intersect   0.000 CPU    0.015 Elapsed)
Qualify (HOUSEHOLDS)HOUSEHOLDS where and STATE = 'CO';
   (15 HOUSEHOLDS, 67 Pre-intersect   0.000 CPU    0.000 Elapsed)
Create index segment O1;
   (15 rows exported   0.000 CPU    0.047 Elapsed)
Qualify (HOUSEHOLDS)HOUSEHOLDS where CITY = 'PHOENIX';
   (11 HOUSEHOLDS, 11 Pre-intersect   0.000 CPU    0.000 Elapsed)
Qualify (HOUSEHOLDS)HOUSEHOLDS where and STATE = 'AZ';
   (11 HOUSEHOLDS, 61 Pre-intersect   0.000 CPU    0.000 Elapsed)
Qualify (HOUSEHOLDS)HOUSEHOLDS where or $ODXID = 'segment(O1)';
   (26 HOUSEHOLDS, 15 Pre-intersect   0.000 CPU    0.000 Elapsed)
Join HOUSEHOLDS using HOUSEHOLD to (INDIVIDUALS)INDIVIDUALS using HOUSEHOLD;
   (64 INDIVIDUALS, 64 Pre-intersect   0.016 CPU    0.016 Elapsed)
Qualify (INDIVIDUALS)INDIVIDUALS where and BIRTHDATE > '"January 1, 1980"';
   (24 INDIVIDUALS, 1,882 Pre-intersect   0.000 CPU    0.000 Elapsed)
Aggregate INDIVIDUALS using GENDER for GROUP(GENDER), COUNT(*);
   (2 rows   0.000 CPU    0.000 Elapsed)
Return I.GENDER, COUNT('*');
-------------------------------------------------------------------------------
> quit
TEXT

The TEXT option displays more information about the expansion of the query due to the use of PowerSearch. PowerSearch allows a query to locate rows even if they do not exactly match the criteria using techniques like synonyms, misspellings, transpositions, word forms, etc. The TEXT option will show the exact search terms after the query was expanded.

The follow query plan shows the expanded search terms for a PowerSearch query. In this example, PowerSearch is being used to find all the synonyms and phonetic equivalents of William, and a wide misspelling search is being used for emails containing Vasquez. The query plan shows that several synonyms for William will be used, and two email addresses that are similar to Vasquez will be included in the search.

> set explain text
> explain
----------------------------------- SUMMARY -----------------------------------
Select        NAME,
              EMAIL
  from        INDIVIDUALS
  where       NAME = 'William' and
              EMAIL = 'vasquez'
  with        OPTIMIZATION=no_cachequal POWERSEARCH;

Version:      5.2.01  (Compiled Feb  2 2012 21:29:57)
----------------------------------- DETAILS -----------------------------------
Qualify (INDIVIDUALS)INDIVIDUALS where NAME = 'synonyms(William,
   "all_given_names") or phonetic(William)' on 1 with NOAUTORESET;
   ----------------------------- Text translation -----------------------------
   in (William, Bill, Billy, Will, Williams, Willie, Willis, Wilson) or
   phonetic(William)
   ----------------------------------------------------------------------------
Qualify (INDIVIDUALS)INDIVIDUALS where and EMAIL = 'misspellings(vasquez,,
   "MIN_SCORE=70")' on 1 with NOAUTORESET;
   ----------------------------- Text translation -----------------------------
   and
   in (kvasquez80, bvasquez912, vasquez)
   ----------------------------------------------------------------------------
Fetchkeys $ROWID 1,000 at a time on 1;
 Retrieve INDIVIDUALS using $ROWID = $ODXID;
 Return INDIVIDUALS.NAME, INDIVIDUALS.EMAIL;
-------------------------------------------------------------------------------

NODES

will provide a basic level of information, Omnidex always optimizes a query as well as it can using the Omnidex indexes; however, if the indexes are not enough, Omnidex will complete the query without indexes, insuring the correct result. In fact, Omnidex can process queries even when no Omnidex indexes are available at all. In this way, Omnidex is first and foremost a SQL Engine for both relational and non-relational, or NoSQL, databases.

Omnidex will evaluate the query and identify where indexes can be used. Omnidex evaluates the tables and their join relationships. Omnidex evaluates criteria, including nested queries, SQL functions and complex Boolean operations. Omnidex evaluates group by and order by, both to perform aggregations and to avoid unnecessary sorting of data. Omnidex even considers whether indexes can be used to return columns in the result set, avoiding accessing the data whenever possible. If there are not indexes to satisfy any of these steps, it will process then without the aid of indexing.

The optimization plan for a query shows a sequence of steps, including table joins, processing criteria, aggregating data, and retrieving from the database. The ideal with Omnidex optimization is to avoid retrieving from the database if possible, and to fully optimize the query solely through the Omnidex indexes. If non-indexed steps are required, optimization tries to minimize these steps as much as possible.

Obtaining a Query Plan

Query plans are produced using the EXPLAIN command in OdxSQL. A plan can be obtain by preceding the SELECT statement with the word EXPLAIN, as shown in the example below:

> explain select name, phone, email from individuals;
----------------------------------- SUMMARY -----------------------------------
Select        NAME,
              PHONE,
              EMAIL
  from        INDIVIDUALS;

Version:      5.2.01  (Compiled Jan 23 2012 17:27:25)
Warnings:     SEQUENTIAL_SCAN
----------------------------------- DETAILS -----------------------------------
Retrieve INDIVIDUALS sequentially;
Return INDIVIDUALS.NAME, INDIVIDUALS.PHONE, INDIVIDUALS.EMAIL;
-------------------------------------------------------------------------------

A plan consists of two sections: the Summary and the Details. The Summary section shows the SQL statement, the version of Omnidex, any optimization settings or warnings that affect the query, and even occasional suggestions for optimizing the query. The Details section shows the steps that will be executed to satisfy the query. Steps are executed in the order displayed, and are indented as needed to show loops of instructions.

In the simple example above, three columns are retrieved from the INDIVIDUALS table. Since no criteria was provided in a WHERE clause, the details of the plan show that the table is retrieved sequentially and the columns are returned. A simple warning indicates that a sequential scan is taking place, which in this case cannot be avoided.

Additional Resources

See also:

 
Back to top
admin/optimization/plans/configuration.1328292282.txt.gz · Last modified: 2016/06/28 22:38 (external edit)