This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
admin:features:segments:home [2012/02/27 21:48] doc created |
admin:features:segments:home [2016/06/28 22:38] (current) |
||
|---|---|---|---|
| Line 8: | Line 8: | ||
| **[[admin:features:segments:home|Overview]]** | | **[[admin:features:segments:home|Overview]]** | | ||
| - | [[admin:features:segments:types|Segment Types]] | | + | [[admin:features:segments:index|Index Segments]] | |
| [[admin:features:segments:creating|Creating Segments]] | | [[admin:features:segments:creating|Creating Segments]] | | ||
| - | [[admin:features:segments:queries|Querying Segments]] | | + | [[admin:features:segments:querying|Querying Segments]] | |
| - | [[admin:features:segments:archiving|Archiving Segements]] | + | [[admin:features:segments:dropping|Dropping Segments]] |
| ---- | ---- | ||
| ==== Overview ==== | ==== Overview ==== | ||
| + | |||
| + | Some applications process their queries in multiple steps. The first step isolates some rows based on a first group of criteria. The second step either refines those rows, or isolates a new set of rows based on a second group of criteria. At the end of the query, all of the steps are combined to produce a final result set. | ||
| + | |||
| + | With relational databases, these multi-step queries are often done by managing a series of temporary tables, usually containing only one column such as a primary key. Each step of the query refines these temporary tables, ultimately producing a final table with the final result set. This approach is significantly slower due to the writing and rewriting of the temporary tables; however, the need for this approach can be a fundamental requirement of the application. | ||
| + | |||
| + | Omnidex Segments provide a higher-speed approach to multi-step queries. Instead of writing and rewriting temporary tables, Omnidex Segments will record the index pointers for each step into temporary objects and allow those segments to be reused in future queries. These index segments are much more efficient than temporary tables, and can be directly applied against Omnidex indexes in future queries. This greatly improves the performance of multi-step queries. | ||
| + | |||
| ==== ==== | ==== ==== | ||
| - | **[[admin:features:segments:types|Next]]** | + | **[[admin:features:segments:creating|Next]]** |