Partition Indexes
Partition Indexes are used in conjunction with record filtering predicates to speed the selection of a subset of records based on some exact matching criteria, e.g. search only those patient records with a date of birth within two years of May 8, 1964. See dbparlists in Invoking TIBCO Patterns Matching (lkt_dbsearch) for how to specify a filtering predicate, and Predicate Expressions for a description of predicates in general.
Partition indexes are defined for a table when the table is created. Indexes can neither be added nor removed after a table is created. A partition index is only effective with the GIP prefilter. A partition index is defined by adding a LPAR_LST_PIDXDEF LPAR to the dbpars parameter of the lkt_dbload command (see Loading a Database (lkt_dbload) containing the following items:
| • | LPAR_INT_PIDXTYPE: Partition indexes are created as either primary or secondary indexes. A primary index provides greater improvements in speed especially for large tables and highly selective filtering predicates, but at the cost of significantly higher memory usage to store the index. Set this LPAR to 1 for a primary index, 0 for a secondary index. All other values are invalid and are rejected. |
Default value: None. This LPAR is required.
| • | LPAR_STR_PIDXFIELD: Each index must be associated with exactly one field in the table. The field might be of any data type, it need not be a searchable text field. |
Default value: None. This LPAR is required.
| • | LPAR_BLKARR_PIDXPARTITIONS: A partition index works by partitioning records into groups based on the value of a selected field. This LPAR is used to define partitions for the field selected by the LPAR_STR_PIDXFIELD LPAR. Each value in this block array defines the upper limit value of a partition in the index. |
The values given must be valid for the field type of the selected field. For example, if the field type is integer, all values in this block array must be valid American Standard Code for Information Interchange (ASCII) representations of integers.
In addition to being valid values for the field type they must be given in sort order from lowest to highest. The sort order is based on the field type. Thus if the field type is integer a valid ordering would be "20", "100", "1000". But if the field type was searchable text this would be an invalid ordering as 20 would sort after the other values in a lexical sort.
The number of partitions in the index are equal to the number of elements in this block array plus three. There is an additional partition to hold all values greater than the last element in this array. In addition there are always two special partitions for records with empty values in the selected field and records with invalid values in the selected field. There is a limit on the number of partitions that might be defined. Currently this limit is set to 1026, therefore there might be no more than 1023 entries in this block array.
An example of a partition set for the state field of an address would be the ordered list of state codes: AL, AK, AZ, ...WY.
Default value: None. This LPAR is required.
| • | LPAR_BOOL_PIDXNORMALIED: When comparing against text data predicate comparisons might be against either the raw field value or the normalized data. Normalization consists of mapping all letters to a common case (thus normalized comparisons are also referred to as case insensitive), removing diacritic marks, and a number of other operations. If indexing a text field you must specify whether you wish to index for the normalized, i.e. case insensitive, comparisons or the raw data comparisons. Include this LPAR and set it to true to index for normalized comparisons. Do not include it or set it to false to index for raw comparisons. If the indexed field is not a text field this LPAR is ignored. |
Default value: False.
Any number of indexes might be defined for a table. A field might have multiple indexes. For example, you might create both a normalized and a raw index on a text field.
You might define multiple primary indexes, however each additional primary index after the first one incur a very large overhead in memory usage. The first primary index incurs a moderate amount of overhead, secondary indexes have low overhead.
When used correctly primary indexes can provide a very large speed up in query through put. Primary indexes provide the best advantage on very large tables where the filtering predicate selects only a small percentage of the total number of records. Generally, if a predicate expression filters out over 95 percent of all records a primary index provides a large advantage over secondary or no index. If the predicate expression generally filters out less than 90 percent of records a secondary index might be suitable. If the predicate expression filters out only a few percent of records it is probably not worth creating an index.
It is important to note that not all predicate expressions that involve an indexed field can take advantage of the index. Only comparisons based on the native field value can use the index. For example, if there is an index on the text field: "birthday" a predicate expression of the form:
DATE $"birthday" > DATE "12/7/1986"
is not able to take advantage of the index as the value is converted to DATE before being compared.
The operators IN, I_IN, SUBSET, SUPERSET and predicate functions do not work with predicate indexes. So even if the address field is indexed, the predicate expression:
"Main" IN $"address"
is not be able to take advantage of the index and gets no improvement in performance.
Additionally, combining expressions with a mix of AND and OR operators might make it impossible to take advantage of the indexes on the table. Consult your TIBCO representative for help in selecting the indexes and predicate expressions that are best for your particular situation.