This is an old revision of the document!
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.
The following is a rather straightforward query that joins two tables together — Individuals and their respective Households — and aggregates counts of all people born since 1980 that are either in Denver, CO or in Phoenix, AZ. The result is a display of counts by Gender. Let's take a look at how Omnidex optimizes this query.
|
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 |
Omnidex must first determine the best processing order for the query. This is determined based on analyzing the table relationships and the select items. Generally speaking, Omnidex needs to end up in the table where the select items or aggregations reside, and must process the other tables first. In this example, Omnidex will recognize that the HOUSEHOLDS table is the parent table, and the query will aggregate data in the INDIVIDUALS table. It will process the HOUSEHOLDS criteria first.
|
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 |
<-- |
Since this query will aggregate the INDIVIDUALS table, Omnidex will need to process the HOUSEHOLDS first and then end in the INDIVIDUALS table. |
Omnidex will perform index qualifications to process the criteria in the HOUSEHOLDS table, paying attention to Boolean operators and parentheses to insure the correct result. Once this is done, Omnidex will have isolated the rows that meet this criteria, identified by a temporary file containing index pointers.
|
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 |
<-- |
Omnidex will use the STATE and CITY indexes to process the HOUSEHOLDS table's criteria, paying attention to Boolean operators and parentheses. |
Omnidex will join from the HOUSEHOLDS table to the INDIVIDUALS table. Omnidex has several techniques for optimizing table joins. In this case, it will use the primary key values in HOUSEHOLDS as criteria against thed HOUSEHOLD index in the INDIVIDUALS table. Once this is done, Omnidex will have isolated rows in the INDIVIDUALS table that meet the criteria from the HOUSEHOLDS table.
|
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 |
<-- |
Omnidex will use the primary keys from the HOUSEHOLDS table as criteria against the HOUSEHOLD index in the INDIVIDUALS table to process this table join. |
Omnidex will perform index qualifications to process the criteria in the INDIVIDUALS table. This will further refine the index pointers already identified by processing in the HOUSEHOLDS table.
|
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 |
<-- |
Omnidex will use the BIRTHDATE index to process the INDIVIDUALS table's criteria. |
Omnidex will aggregate counts in the INDIVIDUALS table by scanning its indexes and filering the results using the index pointers set aside from the previous steps.
|
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 |
<-- |
Omnidex will use the GENDER index to aggregate counts for the rows that have been isolated previously. |
See also: