Any that I missed?
Vi vs. Emacs? (answer: joe) cvs vs. git vs. svn (answer: svn) python versus perl (answer: Python) C vs C++ (answer: C, but only because I have had patches accepted) fbsd vs linux (answer: my nick is linupoet, you guess) Red versus Blue (answer: They both suck)
As always we let our submissions define our actual tracks. If you have something you want to talk about it. Submit it. As long as it is about PostgreSQL (or doing something with PostgreSQL) we will consider it.
We are seeking creative ideas about things we can do at the conference. At West we had a code sprint. The sprint was very successful as it was about all things postgresql and open source. It wasn't just hacking back end code but people worked on all kinds of things.. Is someone up for running a code sprint?
There has also been specific interest in having us add (in addition to our advanced topics) a newbie track. Please do not be afraid to submit a talks on items such as:
Backing up PostgreSQL Understanding and Configuring Autovacuum Normalization Trigger Happy (how to use triggers ;) PITR -- happiness is a shipped transaction log
Other topics we are interested in beyond the standard PostgreSQL architectural fanfare are:
So don't delay, PostgreSQL Conference, U.S. is the premeire PostgreSQL conference series for the United States PostgreSQL community! Submit your talk today.
Groovy/Grails Django PHP Pylons SQL Alchemy
A CHECK constraint is easy to apply and has simple syntax. It is also extremely flexible in solving other types of validating problems. If your valid values change you must DROP CONSTRAINT and ADD CONSTRAINT. You can not add an element to the CHECK.
A Foreign Key creates the requirement of a lookup table. It also offers the easiest management of valid values. You just INSERT, UPDATE or DELETE from the lookup table. If you are a smart monkey and using natural keys versus artificial ones, you can avoid the JOIN on SELECT as well.
ENUM registers as a type in PostgreSQL. This means if you use an ENUM extensively you are basically locking yourself into the use of the type. In short if you need to modify an ENUM you drop the ENUM and recreate it. You can't drop an ENUM if a relation is using it. There are some interesting functions available with ENUM but I am having a hard time seeing a use case for the type as a whole. An ENUM type in theory lends itself specifically to this type of problem so I have included it.
A DOMAIN for this problem suffers from the same problems as ENUM as it registers as a type. However a DOMAIN is more flexible as you can apply complex logic to the validation (just as you can with a CHECK). For example a DOMAIN could contain the regex to validate if a email address is correctly formed. I have used domains many times in the past to create complex validating types. They are useful.
So what does all this boil down to? I have listed the pros and cons of managing each method above but what I haven't mentioned is performance. What is the particular performance bottleneck for each method? Read on, to find out for yourself.
In all it is by far the simplest and most effective tool for PostgreSQL standby that I have used (of course I wrote it so...). Read more...
Auto initialization of environment Simple base backups Monitoring of Master Arbitrary alerts Failover Failover actions etc...
master-->forwarder0 | | ----------------- | | | s0 s1 s2
master-->mcp | | ----------------- | | | s0 s1 s2The mcp would handle all communication and data transfer between the master and the slaves. The idea behind the architecture was to achieve maximum efficiency for the master, meaning that the number of the slaves never affected the performance of the master. However this architecture came with a cost. A single point of failure. If the mcp were to ever crash, replication would stop. When we started down the path of 1.9 it was made very clear to me by Alvaro and Alexey that this was not acceptable. In return I made it very clear that any architectural change we made must not suffer from the Slony problem (performance degradation based on number of subscribers). Together we were all very clear to each other and Alvaro came up with a new architecture. The new architecture calls for a "Forwarder" process and from a topological view doesn't look much different than the MCP. It does however offer us a great deal more flexibility and stability. Here is the new architecture:
master-->forwarder0 | | ----------------- | | | s0 s1 s2How is this different? It is different in a couple of ways. First, the forwarder is now integrated into the PostgreSQL backend. This removes the mcp binary entirely. It also greatly decreases the redundancy of the code. Secondly if the primary forwarder goes down a slave can become the forwarder. This removes the single point of failure. You can read more information on the forwarder here. Other items up for idle thoughts on the possibilities of this new architecture is a single monitoring point. With versions of replicator <= 1.8, you can have a clear idea of which replication transactions have been received and transfered to each slave but you must access each slave individually to see what transaction has actually been restored. So what else is coming with Replicator 1.9? In continuing our cleanup of the architecture we are completely rewriting the ROLE and GRANT/REVOKE replication. This is actually the first step of the other half of the Major Feature of Replicator 1.9, DDL replication. We are currently investigating the opportunity to have certain DDL operations automatically replicate. The most obvious of these would be:
We decided to pass on replicating CREATE FUNCTION due to complexity in dealing with externally linked libraries as well as various dependency problems. We may look at this again in the future. For more information on this feature please visit the thread. If you are interested in testing you can grab the 1.8 Beta or 1.9 from SVN. You can also get the 1.8 Beta from The pgsqlrpms project. The next developer meeting is on 01.08.09 at 11:00AM PST. We are holding in in the #replicator channel on Freenode. All are welcome.
CREATE TABLE ALTER TABLE CREATE DOMAIN etc...
PostgreSQL Partitioning - Robert Treat Babel of PLs - David Fetter