On Wed, Sep 15, 2004 at 02:09:31PM -0700, J. Andrew Rogers wrote:
> On Tue, 2004-09-14 at 21:30, Joe Conway wrote:
> > That's exactly what we're doing, but using inherited tables instead of a
> > union view. With inheritance, there is no need to rebuild the view each
> > time a table is added or removed. Basically, in our application, tables
> > are partitioned by either month or week, depending on the type of data
> > involved, and queries are normally date qualified.
>
>
>
> We do something very similar, also using table inheritance and a lot of
> triggers to automatically generate partitions and so forth. It works
> pretty well, but it is a custom job every time I want to implement a
> partitioned table. You can save a lot on speed and space if you use it
> to break up large tables with composite indexes, since you can drop
> columns from the table depending on how you use it. A big part of
Forgive my ignorance, but I didn't think you could have a table that
inherits from a parent not have all the columns. Or is that not what you
mean by 'you can drop columns from the table...'?
This is one advantage I see to a big UNION ALL view; if you're doing
partitioning based on unique values, you don't actually have to store
that value in the partition tables. For example,
http://stats.distributed.net has a table that details how much work each
participant did each day for each project. Storing project_id in that
table is an extra 4 bytes... doesn't sound like much until you consider
that the table has over 130M rows right now. So it would be nice to have
an easy way to partition the table based on unique project_id's and not
waste space in the partition tables on a field that will be the same for
every row (in each partition).
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"