linkend="indexes-partial-ex2">. This results in the same
advantages as listed above, but it prevents the
- uninteresting
values from being accessed via an
+ uninteresting
values from being accessed via that
index at all, even if an index scan might be profitable in that
case. Obviously, setting up partial indexes for this kind of
scenario will require a lot of care and experimentation.
Setting up a Partial Index to Exclude Uninteresting Values
- If you have a table that contains both billed and unbilled orders
+ If you have a table that contains both billed and unbilled orders,
where the unbilled orders take up a small fraction of the total
- table and yet that is an often used section, you can improve
- performance by creating an index on just that portion. The
- command the create the index would look like this:
+ table and yet those are the most-accessed rows, you can improve
+ performance by creating an index on just the unbilled rows. The
+ command to create the index would look like this:
CREATE INDEX orders_unbilled_index ON orders (order_nr)
WHERE billed is not true;
This is not as efficient as a partial index on the
amount column would be, since the system has to
- scan the entire index in any case.
+ scan the entire index. Yet, if there are relatively few unbilled
+ orders, using this partial index just to find the unbilled orders
+ could be a win.
also illustrates that the
indexed column and the column used in the predicate do not need to
match.
PostgreSQL supports partial
- indexes with arbitrary predicates, as long as only columns of the
+ indexes with arbitrary predicates, so long as only columns of the
table being indexed are involved. However, keep in mind that the
- predicate must actually match the condition used in the query that
- is supposed to benefit from the index.
+ predicate must match the conditions used in the queries that
+ are supposed to benefit from the index. To be precise, a partial
+ index can be used in a query only if the system can recognize that
+ the query's WHERE condition mathematically implies
+ the index's predicate.
PostgreSQL does not have a sophisticated
theorem prover that can recognize mathematically equivalent
predicates that are written in different forms. (Not
only is such a general theorem prover extremely difficult to
create, it would probably be too slow to be of any real use.)
+ The system can recognize simple inequality implications, for example
+ x < 1
implies x < 2
; otherwise
+ the predicate condition must exactly match the query's WHERE condition
+ or the index will not be recognized to be usable.
+ A third possible use for partial indexes does not require the
+ index to be used in queries at all. The idea here is to create
+ a unique index over a subset of a table, as in
+ linkend="indexes-partial-ex3">. This enforces uniqueness
+ among the rows that satisfy the index predicate, without constraining
+ those that do not.
+
+
+
+
Setting up a Partial Unique Index
+
+ Suppose that we have a table describing test outcomes. We wish
+ to ensure that there is only one successful entry for
+ a given subject and target combination, but there might be any number of
+ unsuccessful entries. Here is one way to do it:
+CREATE TABLE tests (subject text,
+ target text,
+ success bool,
+ ...);
+CREATE UNIQUE INDEX tests_success_constraint ON tests (subject, target)
+ WHERE success;
+
+ This is a particularly efficient way of doing it when there are few
+ successful trials and many unsuccessful ones.
+
+
+
Finally, a partial index can also be used to override the system's
query plan choices. It may occur that data sets with peculiar
projects / postgresql.git / commitdiff