Location

UNIQUE is no longer unique among constraints. I authored "Exclusion Constraints" for PostgreSQL 8.5: a more general constraint mechanism that can enforce constraints such as "non-overlapping" as well as unique; and can enforce constraints on GiST or hash indexes as well as BTree. See why other constraint mechanisms are unsuitable for common business requirements -- like handling schedule conflicts -- and how the problems are solved by using Exclusion Constraints.

Exclusion Constraints are a more general constraint enforcement mechanism than UNIQUE; new in PostgreSQL 8.5. The constraints specify the conditions under which two tuples conflict, and concurrent updates are resolved with the same semantics as UNIQUE.

The existing UNIQUE constraints are a special case of Exclusion Constraints in which the two tuples conflict if all columns in the constraint are equal. Exclusion Constraints allow other operators to be specified. For instance, a reservation system may require that two tuples conflict if the room numbers are equal and the reservation periods overlap (as part of the demonstration, I make use of a user-defined PERIOD data type). Any operator can be specified as long as it is binary, boolean, commutative, and there's an operator class for the required index search (which is used to check for conflicts, much like the existing UNIQUE constraint mechanism).

Exclusion Constraints are important because they are easy, scalable, flexible and general to many different business needs. See why alternatives and workarounds all have serious problems and limitations, and how they are solved by using Exclusion Constraints.

Location

Getting to know the Postgres way

Experience in one database system does not always make learning another one easy. Although Postgres is more SQL-compliant than just about anything else, there are plenty of quirks, features, and gotchas that you should be aware of.

Postgres has an active and thriving community. We'll explore what makes the project unique, from developer philosophy to SQL features to advocacy, and everything in between. If you are coming from another database system, this will get you up to speed on the important differences between Postgres and everything else.

Location

The NoSQL movement has captured the attention of many web developers, often times using the myth that SQL databases like PostgreSQL do not scale as well as newer technologies. We wil examine many of the more popular key/value store databases and illustrate the pros and cons of using a "NoSQL" database, examining the features of the more popular NoSQL alternatives in comparison to PostgreSQL. More importantly, we will address the impact of NoSQL technology at scale as it compares to PostgreSQL and ultimately discover why PostgreSQL is the YesQL alternative to today's upstart database technologies.

Key/Value database stores are not new technology, but 2009 was the year of alternative "NoSQL" databases. In this talk, alternative databases such as CouchDB, Tokyo Tyrant, Redis, MongoDB, Cassandra and Project Voldemort will covered, providing a feature and performance comparisons to PostgreSQL. We will examine the technical and business impact of using alternative database technologies such as those listed and review their technical strengths and weaknesses.

While the PostgreSQL content itself will be limited to how PostgreSQL compares to these technologies, the content should satisfy both developer and dba interest in the subject. In summary, we will review what PostgreSQL can learn from these newer projects and what needs to be done to broaden PostgreSQL's appeal to the many web development communities.