Re: plan time of MASSIVE partitioning ...

I wrote:
> samples % symbol name
> 447433 47.1553 get_tabstat_entry
> 185458 19.5456 find_all_inheritors
> 53064 5.5925 SearchCatCache
> 33864 3.5690 pg_strtok

> get_tabstat_entry and find_all_inheritors are both obviously O(N^2) in
> the number of tables they have to deal with. However, the constant
> factors are small enough that you need a heck of a lot of tables
> before they become significant consumers of runtime. I'm not convinced
> that we should be optimizing for 9000-child-table cases.

> It'd be worth fixing these if we can do it without either introducing a
> lot of complexity, or slowing things down for typical cases that have
> only a few tables. Offhand not sure about how to do either.

I had a thought about how to make get_tabstat_entry() faster without
adding overhead: what if we just plain remove the search, and always
assume that a new entry has to be added to the tabstat array?

The existing code seems to be designed to make no assumptions about
how it's being used, but that's a bit silly. We know that the links are
coming from the relcache, which will have only one entry per relation,
and that the relcache is designed to hang onto the links for (at least)
the life of a transaction. So rather than optimizing for the case where
the relcache fails to remember the tabstat link, maybe we should
optimize for the case where it does remember.

The worst-case consequence AFAICS would be multiple tabstat entries for
the same relation, which seems pretty noncritical anyway.

Thoughts?

regards, tom lane