Hi,
> The only problem I have with this is that the shops I know with big
> partitioned tables favor triggers over rules for both performance reason
and
> a cleaner implementation. Even with automated rule creation this isnt
going
> to change afaics... not to mention we already create our rules &
triggers
> automatically, so really this just isn't exciting to me (though it may
make
> it easier for people getting in on the ground floor)
I second this. The trigger route is much more maintainable than the rule
route. IMO what really needs to happen is something more low level where
there are no DBA visible changes. Triggers also have overhead, it would
be nice to get a little more bare metal with this.
I had raised this issue about rules/triggers back then and the responses
seemed to be evenly split as to which ones to use.
I think the broad question really is how well we want to support the current
inheritance based partitioning mechanism. If we want to stick to it for a
while (and to which we will stick to unless something concrete/better/"bare
metal" comes up), IMHO we should try to make things simpler (by automating
things if possible) to make it easier for people getting in.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
