This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
admin:indexing:strategies:aggregations [2012/01/26 23:19] doc |
admin:indexing:strategies:aggregations [2012/01/30 18:05] doc |
||
|---|---|---|---|
| Line 17: | Line 17: | ||
| ==== Optimizing Count Aggregations ==== | ==== Optimizing Count Aggregations ==== | ||
| - | Count aggregations are grouped or ungrouped counts that match any of the following constructs: | + | Count aggregations are any SELECT statements that request "COUNT(*)", "COUNT(column)", or "COUNT(DISTINCT column)", regardless of whether there is a GROUP BY clause. These queries are optimized using a collection of Omnidex indexes. Each column that is referenced in the GROUP BY clause and referenced in the COUNT clause must be indexed using a standard Omnidex index. Omnidex will use all of these indexes in combination to optimize the query. |
| - | <code SQL> | + | The advantage of this optimization approach is that a small number of indexes can support nearly any combination of GROUP BY columns, providing high performance at little cost. |
| - | select count(*) from <table>; | + | There are some situations in which specialized indexes are better for optimizing a query. When a GROUP BY column has especially high cardinality, such as over 64,000 distinct values, it is necessary to create a multi-column index as described below. Additionally, if the same GROUP BY columns are used frequently, a multi-column index will provide even faster performance. |
| - | select count(distinct <column>) from <table>; | + | |
| - | select count(*) from <table> where <criteria>; | + | |
| - | select count(distinct <column>) from <table> where <criteria>; | + | |
| - | select <column>, count(*) from <table> where <criteria> group by <column>; | + | |
| - | select <column>, count(distinct <column>) from <table> where <criteria> group by <column>; | + | |
| - | </code> | + | |
| ==== Optimizing Other Aggregations ==== | ==== Optimizing Other Aggregations ==== | ||
| - | + | Aggregations that use the SUM, AVERAGE, MIN and MAX functions are optimized by creating an index containing all of the columns in the GROUP BY clause and all of the columns referenced in SUM, MIN, MAX and AVERAGE functions. It is preferable to have the columns in the GROUP BY clause precede the columns being aggregated. The order of the GROUP BY columns does not make much difference, though if the same GROUP BY clause is repeated used, then order the columns in the index the same way. | |
| - | by creating an index containing all of the columns in the GROUP BY clause and all of the columns referenced in COUNT, SUM, MIN, MAX and AVERAGE functions. It is preferable to have the columns in the GROUP BY clause precede the columns being aggregated. | + | |
| - | + | ||
| - | The COUNT(*) aggregation is treated uniquely. The use of the asterisk does not equate to an individual column and does not expand the side of the index. In fact, Omnidex maintains counts at each step of the search, so simple COUNT(*) aggregations do not need specialized indexing. | + | |
| Some applications will use GROUP BY clauses that consist of columns from a child table and columns from parent or grandparent tables. In these cases, the Omnidex index in the child should include all columns from the child table as well as the foreign keys that point to the parent table. | Some applications will use GROUP BY clauses that consist of columns from a child table and columns from parent or grandparent tables. In these cases, the Omnidex index in the child should include all columns from the child table as well as the foreign keys that point to the parent table. | ||
| It is fine for one index to service multiple aggregations. This occurs when one index contains a superset of all of the columns for several queries. For example, an index on columns A, B, C and D would allow sums of D grouped by A, and also averages of D and C grouped by B and A. The performance of these aggregations will begin to degrade as the index width increases, so indexes should not contain an excessive number of columns. A good rule of thumb is to keep the width of these indexes below 64 bytes, though they can be as large as 240 bytes. | It is fine for one index to service multiple aggregations. This occurs when one index contains a superset of all of the columns for several queries. For example, an index on columns A, B, C and D would allow sums of D grouped by A, and also averages of D and C grouped by B and A. The performance of these aggregations will begin to degrade as the index width increases, so indexes should not contain an excessive number of columns. A good rule of thumb is to keep the width of these indexes below 64 bytes, though they can be as large as 240 bytes. | ||
| + | |||
| + | ==== Examples ==== | ||
| == Example 1. Ungrouped COUNT(*) aggregations == | == Example 1. Ungrouped COUNT(*) aggregations == | ||