Not Just UNIQUE: Generalized Index Constraints

1,739 views
1,671 views

Published on

Jeff Davis

UNIQUE indexes have long held a unique position among constraints: they are the only way to express a constraint that two tuples in a table conflict without resorting to triggers and locks (which severely impact performance). But what if you want to impose the constraint that one person can't be in two places at the same time? In other words, you have a schedule, and you want to be sure that two periods of time for the same person do not overlap. This is nearly impossible to do efficiently with the current version of PostgreSQL -- and most other database systems. I will be presenting Generalized Index Constraints, which is being submitted for inclusion in the next PostgreSQL release, along with the PERIOD data type (available now from PgFoundry). I will show how these can, together, offer a fast, scalable, and highly concurrent solution to a very common business requirement. A business requirement is still a requirement even if your current database system can't do it!

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,739
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Not Just UNIQUE: Generalized Index Constraints

  1. 1. Not just UNIQUE Jeff Davis Truviso, Inc. 1
  2. 2. Why is UNIQUE so unique? ● Only constraint where two tuples can conflict with eachother – That is, the existence of one tuple precludes others from existing ● Effectively a predicate lock on a very simple predicate ● Special code to enforce unique constraint in the BTree code – doesn't work GiST, etc. 2
  3. 3. Motivation for More General Constraints ● PERIOD data type can represent a period of time: – http://pgfoundry.org/projects/temporal ● Definite beginning and end time, e.g., the period of time during which a professor is teaching in a classroom ● But two professors can't teach in the same classroom at the same time ● So periods of time cannot overlap 3
  4. 4. Digression: Temporal Data ● Managing temporal data effectively is important and a very common problem. ● Hopefully you saw Scott Bailey's talk earlier – if not, wait for the video. ● Enforcing non-overlapping constraints is one of the few pieces that requires good support in the core PostgreSQL engine. 4
  5. 5. Non-Overlapping Constraint ● Very commonly known as a “schedule conflict” ● How do you specify a non-overlapping constraint in PostgreSQL currently? ● Any ideas? 5
  6. 6. Non-Overlapping Constraint ● Very commonly known as a “schedule conflict” ● How do you specify a non-overlapping constraint in PostgreSQL currently? ● Any ideas? ● Most people don't enforce in DBMS ● Maybe with a trigger that takes a full table lock? – Horrible performance 6
  7. 7. Non-Overlapping Constraint ● If the constraint is not enforced by the database... ● ...then it will be enforced when two professors each believe they have reserved the same room ● A duel? ● Probably a less desirable constraint enforcement mechanism than a friendly error from the DBMS 7
  8. 8. Operator Exclusion Constraints ● New feature ● Working on getting it accepted for PostgreSQL 8.5 ● Offers more general constraint enforcement mechanism 8
  9. 9. Example CREATE TABLE reservation (   room      TEXT,   professor TEXT,   during    PERIOD,   EXCLUSION USING gist     (room   CHECK WITH =,      during CHECK WITH &&) ); 9
  10. 10. Example CREATE TABLE reservation (   room      TEXT,   professor TEXT,   during    PERIOD,   EXCLUSION USING gist     (room   CHECK WITH =,      during CHECK WITH &&) ); Can be arbitrary expression of fields in table. 10
  11. 11. Example CREATE TABLE reservation (   room      TEXT,   professor TEXT,   during    PERIOD,   EXCLUSION USING gist     (room   CHECK WITH =,      during CHECK WITH &&) ); Exclusion operator. In this case, “overlaps”. 11
  12. 12. Example CREATE TABLE reservation (   room      TEXT,   professor TEXT,   during    PERIOD,   EXCLUSION USING gist     (room   CHECK WITH =,      during CHECK WITH &&) ); Type of index to build and use for enforcement. 12
  13. 13. Operator Detects Conflicts ● The operator is used to search for conflicts ● Should return TRUE when two values conflict ● Should return TRUE when two values conflict ● So the “overlaps” operator (“&&”) would be used to enforce the constraint that no two tuples contain overlapping values 13
  14. 14. Back to UNIQUE ● If you specify all operators as “=”, the semantics are identical to UNIQUE ● Performance slightly worse, because one additional index search is required ● But can be used with GiST 14
  15. 15. UNUNIQUE ● If you specify all operators as “<>”, then constraint is the opposite of unique: all values must be the same! ● However, won't work for types that don't have a search strategy for “<>”. ● Not obviously useful, but it's there. 15
  16. 16. Multi-Column Constraints ● ... EXCLUSION USING gist       (a CHECK WITH =,        b CHECK WITH &&) ... ● Tuple1 conflicts with Tuple2 if and only if: – Tuple1.a =  Tuple2.a AND – Tuple1.b && Tuple2.b ● Otherwise, both tuples can appear in the table. 16
  17. 17. Extra Capabilities ● Support for predicates (WHERE) – Constraint on a subset of the table ● Support for arbitrary expressions – ... EXCLUSION ((t::circle)  CHECK WITH &&) ... ● Can use other tablespaces and index parameters, similar to UNIQUE. ● Deferrable (work in progress) ● GIN support (work in progress) 17
  18. 18. Future Work ● Multiple constraints can use the same index ● UNIQUE(a, b) and UNIQUE(a, c) can both use an index on (a, b, c) ● Depending on selectivity of “a”, may perform much better than two separate indexes 18
  19. 19. Conclusion ● Constraints are always enforced ● Sometimes by the DBMS (cheap), sometimes by real life (expensive) ● The very simple, very common “schedule conflict” constraint is almost impossible to enforce with most DBMSs ● Let's make it easy, scalable, and flexible. ● “Operator Exclusion Constraints” in 8.5 19

×