Re: Stats for inheritance trees

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On Mon, 2009-12-28 at 17:41 -0500, Tom Lane wrote:
>> 2. When ANALYZE is invoked on a table that has inheritance children,
>> it will perform its normal duties for just that table (creating or
>> updating entries with stainherit = false) and then perform a second
>> scan that covers that table and all its children. This will be used
>> to create or update entries with stainherit = true. It might be
>> possible to avoid scanning the parent table itself twice, but I won't
>> contort the code too much to avoid that, since in most practical
>> applications the parent is empty or small anyway.

> Will there be logic to decide how stainherit should be set? Many columns
> in an inherited set have similar values in different children, e.g.
> OrderValue, OrderStatus but many columns also have very different values
> in different children. e.g. OrderId, OrderPlacementDate,
> OrderFulfillmentDate

I don't see that that's relevant here. We're trying to estimate the
overall result of a join against an inheritance tree. The fact that
some or even all of the matching rows might come from specific child
tables is not relevant at this level of detail. When it is relevant,
we'll be looking at the child-table stats (and constraints), not at
the parent's.

regards, tom lane