Re: Table Partitions: To Inherit Or Not To Inherit

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

In response to

Browse pgsql-performance by date

  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