Re: Query plan and Inheritance. Weird behavior

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: John Lange <lists(at)darkcore(dot)net>
Cc: Andras Kadinger <bandit(at)surfnonstop(dot)com>, PostgreSQL <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Query plan and Inheritance. Weird behavior
Date: 2003-01-29 05:05:15
Message-ID: 19547.1043816715@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

John Lange <lists(at)darkcore(dot)net> writes:
> Firstly, from the simple standpoint of database normalization you
> shouldn't have tables that have the same columns. The way it is
> implemented, child tables are copies of parent tables.

There is no copied data though. Or are you saying that if any table
in the database has, say, a timestamp column, then it's a failure of
normalization for any other one to have a timestamp column? Don't think
I buy that.

> But more importantly it is bad for performance because selecting from a
> parent table causes the same select to be done on all the child tables.

So? The same amount of data gets scanned either way. To the extent
that the planner fails to generate an optimal plan in such cases, we
have a performance problem --- but that's just an implementation
shortcoming, not a fundamental limitation AFAICS.

The only real disadvantage I can see to the current storage scheme is
that we can't easily make an index that covers both a parent and all its
children; the index would have to include a table pointer as well as a
row pointer. This creates problems for foreign keys and unique constraints.
But there is more than one way to attack that.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Matt Mello 2003-01-29 06:22:53 1 char in the world
Previous Message John Lange 2003-01-29 03:21:41 Re: Query plan and Inheritance. Weird behavior