Re: plan time of MASSIVE partitioning ...

I wrote:
> This is going to be dominated by constraint exclusion checking.

Hmm, maybe I spoke too soon.  With 9000 child tables I get a profile
like this:

samples  %        symbol name
447433   47.1553  get_tabstat_entry
185458   19.5456  find_all_inheritors
53064     5.5925  SearchCatCache
33864     3.5690  pg_strtok
26301     2.7719  hash_search_with_hash_value
22577     2.3794  AllocSetAlloc
6696      0.7057  MemoryContextAllocZeroAligned
6250      0.6587  expression_tree_walker
5141      0.5418  LockReleaseAll
4779      0.5037  get_relation_info
4506      0.4749  MemoryContextAlloc
4467      0.4708  expression_tree_mutator
4136      0.4359  pgstat_initstats
3914      0.4125  relation_excluded_by_constraints

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