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 (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers