From: | Yann Michel <yann-postgresql(at)spline(dot)de> |
---|---|
To: | Matteo Beccati <php(at)beccati(dot)com> |
Cc: | Matt Casters <Matt(dot)Casters(at)advalvas(dot)be>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: |
Date: | 2005-01-21 16:05:39 |
Message-ID: | 20050121160539.GA15734@zoom.spline.inf.fu-berlin.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2005-01-21 16:08:41 | Re: PostgreSQL clustering VS MySQL clustering |
Previous Message | Bjoern Metzdorf | 2005-01-21 16:04:56 | Re: PostgreSQL clustering VS MySQL clustering |