From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org, Don Drake <dondrake(at)gmail(dot)com> |
Subject: | Re: Table Partitions: To Inherit Or Not To Inherit |
Date: | 2004-11-17 05:51:14 |
Message-ID: | 200411162151.14693.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Don,
> What's really the difference between this and creating separate tables
> with the same column definition without the inherit, and then create a
> view to "merge" them together?
Easier syntax for queries. If you created completely seperate tables and
UNIONED them together, you'd have to be constantly modifying a VIEW which
tied the tables together. With inheritance, you just do "SELECT * FROM
parent_table" and it handles finding all the children for you.
> Also, I've run into a snag in that I have a hourly_detail table, that
> has a foreign key to the hourly_report_data. The inherit method above
> does not honor the foreign key relationship to the children table of
> hourly_report_data. I can't insert any data into the hourly_detail
> table due to the constraint failing.
This is a known limitation of inherited tables, at least in current
implementations. I think it's on the TODO list. For now, either live
without the FKs, or implement them through custom triggers/rules.
--
Josh Berkus
Aglio Database Solutions
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2004-11-17 06:07:50 | Re: nuderstanding 'explain analyse' |
Previous Message | Josh Berkus | 2004-11-17 05:47:54 | Re: memcached and PostgreSQL |