From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Announce" <truthhurts(at)insightbb(dot)com> |
Cc: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: How does PG Inheritance work? |
Date: | 2005-11-28 06:00:35 |
Message-ID: | 524.1133157635@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
"Announce" <truthhurts(at)insightbb(dot)com> writes:
> How does Postgres internally handle inheritance under the following
> scenario?
> Using sample tables similar to a previous post:
> CREATE TABLE employee(id primary key, name varchar, salary numeric(6,2));
> CREATE TABLE programmer(language varchar, project varchar) INHERITS
> (employee);
> CREATE TABLE representative (region varchar) INHERITS (employee);
> Let's say for example's sake, there are 10 million rows of PROGRAMMER data
> but only 100 rows of representative data. Will a query (select, update,
> insert, etc) on the REPRESENTATIVE table take a performance hit because of
> this?
No.
> It seems like the child-table is really not concrete.
What makes you think that?
In this example, queries against EMPLOYEE take a performance hit due to
the existence of the child tables, because they end up scanning all
three tables. Queries directly against a child table do not notice the
inheritance relationship at all.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Saunders | 2005-11-28 08:58:26 | Re: PostgreSQL 8.0.1-2 WinXP Services |
Previous Message | 2005-11-28 00:05:13 | PostgreSQL 8.0.1-2 WinXP Services |