Tom Lane wrote:
>
> Chris <chris@bitmead.com> writes:
> > Why not change that to a relnumindexes as well? Easier to maintain and
> > more useful information.
>
> Maintaining an accurate count of descendants (or indexes for that
> matter) would be expensive; in particular, it'd create severe
> concurrency problems. If one transaction is in the middle of creating
> or dropping a child C of table P, then all other transactions would be
> blocked from creating or dropping any other children of P until the C
> transaction commits or aborts. They'd have to wait or they wouldn't
> know what to set relnumchildren to.
>
> For the purpose at hand, I think it would be OK to have a
> "relhaschildren" field that is set true when the first child is created
> and then never changed. If you have a table that once had children but
> has none at the moment, then you pay the price of looking through
> pg_inherits; but the case that we're really concerned about (a pure SQL,
> no-inheritance table) would still win.
>
> Not sure whether we can concurrently create/delete indexes on a rel,
> but I'd be inclined to leave relhasindexes alone: again its main
> function in life is to let you short-circuit looking for indexes on
> a table that's never had and never will have any.
>
WOuld it be possible to consider this a 'statistic' and let
vacuum update it?
In other words, creating an index (or subtable) sets
relhasindex (relhaschild) but vacuum will set it to false
if it finds no children or indexes. or would this
run into concurrency problems as well?
--
Mark Hollomon
mhh@nortelnetworks.com
ESN 451-9008 (302)454-9008