Thread: inheritance performance

Wondering ...

From a performance standpoint, is it a bad idea to use inheritance
simply as a tool for easy database building.  That is for creating
tables that share the same columns but otherwise are unrelated.

For example, let's say I have the following set of columns that are
common to many of my tables.

objectid       int,
createdby      varchar(32),
createddate    timestamp

... and let's say I create a table with these columns just so that I can
then create other tables that inherit this table so that I have these
columns in it without having to respecify them over and over again
separately for each table that contains them.

From my understanding, all the data for these columns in all the child
tables will be stored in this one parent table and that, furthermore,
there is a "hidden" column in the parent table called tableoid that
allows postgres to determine which row is stored in which child table.

Given that, is there a performance hit for queries on the child tables
because postgres has to effectively put a condition on every query based
on the tableoid of the given child table?

In other words, if say child table A has 10 million rows in it and child
B has 2 rows in it.  Will a query on child table B be slowed down by the
fact that it inherits from the same table as A.  I'm sure the answer is
absolutely yes, and so I guess I'm just looking for corroboration.

Maybe I'll be surprised!

Thanks a bunch,

Ken

ken <southerland@samsixedd.com> writes:

> >From my understanding, all the data for these columns in all the child
> tables will be stored in this one parent table

No, all the data is stored in the child table.

> and that, furthermore, there is a "hidden" column in the parent table called
> tableoid that allows postgres to determine which row is stored in which
> child table.

That's true.

> Given that, is there a performance hit for queries on the child tables
> because postgres has to effectively put a condition on every query based on
> the tableoid of the given child table?

There's a performance hit for the extra space required to store the tableoid.
This means slightly fewer records will fit on a page and i/o requirements will
be slightly higher. This will probably only be noticeable on narrow tables,
and even then probably only on large sequential scans.

There's also a slight performance hit because there's an optimization that the
planner does normally for simple queries that isn't currently done for either
UNION ALL or inherited tables. I think it's planned to fix that soon.

> In other words, if say child table A has 10 million rows in it and child
> B has 2 rows in it.  Will a query on child table B be slowed down by the
> fact that it inherits from the same table as A.  I'm sure the answer is
> absolutely yes, and so I guess I'm just looking for corroboration.

No, it isn't slowed down by the records in A. It's slightly slower because it
is an inherited table, but that impact is the same regardless of what other
tables inherit from the same parent and how many records are in them.

--
greg

On Fri, 2005-01-21 at 08:14, Greg Stark wrote:
> ken <southerland@samsixedd.com> writes:
>
> > >From my understanding, all the data for these columns in all the child
> > tables will be stored in this one parent table
>
> No, all the data is stored in the child table.

So if you perform a "select * from parent" then does postgres internally
create a union between all the child tables and return you the results
of that?

ken

ken <southerland@samsixedd.com> writes:

> On Fri, 2005-01-21 at 08:14, Greg Stark wrote:
> > ken <southerland@samsixedd.com> writes:
> >
> > > >From my understanding, all the data for these columns in all the child
> > > tables will be stored in this one parent table
> >
> > No, all the data is stored in the child table.
>
> So if you perform a "select * from parent" then does postgres internally
> create a union between all the child tables and return you the results
> of that?

Essentially, yes.

--
greg

> So if you perform a "select * from parent" then does postgres internally
> create a union between all the child tables and return you the results
> of that?

Basically, yes.  Kind of.

Chris

On Fri, 21 Jan 2005, Greg Stark wrote:

> There's also a slight performance hit because there's an optimization that the
> planner does normally for simple queries that isn't currently done for either
> UNION ALL or inherited tables. I think it's planned to fix that soon.

Can you explain me in more details what kind of optimization is missing in
that case?

Ioannis Theoharis <theohari@ics.forth.gr> writes:

> Can you explain me in more details what kind of optimization is missing in
> that case?

Uh, no I can't really. It was mentioned on the mailing list with regards to
UNION ALL specifically. I think it applied to inherited tables as well but I
wouldn't know for sure. You could search the mailing list archives for recent
discussions of partitioned tables.

In any acse it was a purely technical detail. Some step in the processing of
the data that could be skipped if there weren't any actual changes to the data
being done or something like that. It made a small but noticeable difference
in the runtime but nothing that made the technique infeasible.

--
greg

Greg Stark <gsstark@mit.edu> writes:
> ken <southerland@samsixedd.com> writes:
>> From my understanding, all the data for these columns in all the child
>> tables will be stored in this one parent table

> No, all the data is stored in the child table.

Correct ...

>> and that, furthermore, there is a "hidden" column in the parent table called
>> tableoid that allows postgres to determine which row is stored in which
>> child table.

> That's true.
> There's a performance hit for the extra space required to store the tableoid.

Bzzzt ...

tableoid isn't actually stored anywhere on disk.  It's a pseudo-column
that is generated during row fetch.  (It works for all tables, not only
inheritance children.)

>> Given that, is there a performance hit for queries on the child tables
>> because postgres has to effectively put a condition on every query based on
>> the tableoid of the given child table?

AFAIR, a query directed specifically to a child table is *completely*
unaware of the fact that that table is a child.  Only queries directed
to a parent table, which have to implicitly UNION in the children, pay
any price for inheritance.

            regards, tom lane