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.
regards, tom lane
