Re: managing table partitions automatically

> 2) Use triggers instead of rules wherever possible
> 3) From the docs: "If more than one trigger is defined for the same
> event on the same relation, the triggers will be fired in alphabetical
> order by trigger name. In the case of before triggers, the
> possibly-modified row returned by each trigger becomes the input to the
> next trigger. If any before trigger returns NULL, the operation is
> abandoned for that row and subsequent triggers are not fired."

> - Josh / eggyknap

Steve,

What you are doing can be implemented with rules or triggers. I wouldn't agree with Josh that in all cases a trigger is better than a rule. It depends on your pattern of inserts and if you are optimizing for speed or manageability or what.

Either way, you will want to put check constraints in each of your tables and have constraint_exclusion = on for your db so you can take advantage of constraint exclusion. And even ask the very fundamental question of if you really have enough data that it makes the most sense to partition right now.

Anyrate Robert Treat's slide is a good primer of how to use both approaches and the pros and cons of each.

http://www.slideshare.net/xzilla/postgresql-partitioning-pgcon-2007-presentation

Just my 2 cents,
Regina

-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.