This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
admin:indexing:concepts:retrieval [2011/01/17 22:22] els |
admin:indexing:concepts:retrieval [2012/01/20 18:08] doc |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | {{page>:top_add&nofooter&noeditbtn}} | + | ~~NOTOC~~ |
| - | ====== Administration: Indexing Strategies ====== | + | {{page>:top_add&nofooter&noeditbtn}} |
| + | ====== Administration: Omnidex Indexing ====== | ||
| ===== Indexing Concepts ===== | ===== Indexing Concepts ===== | ||
| Line 14: | Line 15: | ||
| ---- | ---- | ||
| - | ==== Overview ==== | + | ==== Retrievals ==== |
| - | * Basics of indexing | + | As Omnidex optimizes a query, it looks for ways to use indexes to process criteria, table joins, aggregations and ordering. It may also find that the data to be returned to the user can be obtained from the indexes. This can allow an entire query to be processed without ever accessing the database. This technique provides exceptional performance. |
| - | * Indexing for criteria | + | |
| - | * Basic cost of qualifications | + | |
| - | * Use of multiple indexes | + | |
| - | * MDK_RETRIEVAL_THRESHOLD (rename to QUALIFICATION_THRESHOLD) | + | |
| - | * Indexing for joins | + | |
| - | * Basic costs of joins | + | |
| - | * Prejoined indexes | + | |
| - | * Joining across databases | + | |
| - | * Indexing for aggregations | + | |
| - | * Basic cost of index scan | + | |
| - | * Use of partition qualifiers | + | |
| - | * ASK_RETRIEVAL_THRESHOLD (rename to AGGREGATION_THRESHOLD) | + | |
| - | * Indexing for ordering | + | |
| - | * Similar to aggregations | + | |
| - | * Indexing for retrieval | + | |
| - | * Obtaining data from indexes | + | |
| - | * Base cost of reading the index | + | |
| - | * Alternatives to indexing | + | |
| - | * Full table scans | + | |
| - | * Sort-merge | + | |
| - | * Hashed data caching | + | |
| + | The simplest example of this is queries that request counts. Omnidex always maintains a count of the rows that have been qualified. If the query requests a count, Omnidex can simply return it from the indexes. Other queries may perform aggregations and use GROUP BY clauses. These can be returned from the indexes as well. | ||
| + | Other queries may request primary keys, or even data from other columns. If these columns are found in the indexes, they will be returned from the index in order to minimize retrieval from the database. Omnidex will automatically perform this optimization. | ||
| + | Using these techniques, it is possible to optimize complex queries without ever accessing the database. A query may access dozens of tables, applying a wide variety of criteria and performing aggregations and ordering. If Omnidex can, it will attempt to satisfy all of these aspects in the indexes, providing the best performance possible. | ||
| ===== ===== | ===== ===== | ||
| **[[admin:indexing:concepts:ordering|Prev]]** | **[[admin:indexing:concepts:ordering|Prev]]** | ||
| + | |||
| ====== Additional Resources ====== | ====== Additional Resources ====== | ||