On 22 Jan 2003, John Lange wrote:
> Creating child tables by inheriting from another table doesn't really do
> what I consider to be 'true' inheritance, at least not in the way I
> expected as a programmer.
>
> Postgres seems to create "child" tables by first fully duplicating the
> parent table and then adding the new columns to it. It then links the
> tables internally some how so that a query on a parent table also
> queries the child tables.
That pretty much sums up my understanding of it.
[snip]
> In this way the parent table would not need to know, nor would it care
> about child tables in any way (just like inheritance in most programming
> languages). If done this way a select on a parent table would only
> require the retrieval of a single row and a select on a child table
> would only require the retrieval of two rows (one in the child table and
> one in the parent table).
As opposed to needing one row from a select on a child table and
effectively a union all when selecting from the parent. There are up and
down sides of both implementations, and I haven't played with it enough
to speak meaningfully on it.
> I don't pretend to know the intricacies of Postgres performance but this
> is the way I'm interpreting the data from the explains.
As a side note, for a better understanding of timings, explain analyze is
much better than plain explain which only gives the plan and estimates.