Hi,
On Fri, Jan 21, 2005 at 03:37:20PM +0100, Matteo Beccati wrote:
>
> >>>> CREATE TABLE super_foo ( partition NUMERIC, bar NUMERIC );
> >>>> ANALYZE super_foo ;
> >>>>
> >>>> CREATE TABLE sub_foo1 () INHERITS ( super_foo );
> >>>> CREATE TABLE sub_foo2 () INHERITS ( super_foo );
> >
> >Yes, this could be used instead of a view. But there is one thing
> >missing. You can't just insert into super_foo and aquire the "correct
> >partition". You will still have to insert into the correct underlying
> >table. "Real" partitioning will take care of correct partition
> >selection.
>
> I've recently used this method for partitioning data. In my setup
> inserts are done inside a pl/pgsql function called at regular intervals,
> so this isn't a problem for me. I didn't test it, but I think some rules
> (or a trigger) could do the trick.
Yes, a pl/pgsql function or any software solution can solve this
problem, but what you normally expect from a partitioning support is
that you don't have to care about where to put your data due to the db
will take care for that.
Of cause a trigger could do this as well, but don't forget, that a
trigger in dwh environments, where you process thousands of row at once
during data loading, is very expensive and therefore no solution for
production use.
Regards,
Yann
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
