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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
