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