I wrote: > I'm still feeling a bit annoyed with the behavior of the stats machinery > (pgstat_initstats and related macros). > ... That means more UDP traffic and more work for > the stats collector. gprof won't show the resulting overhead since > it doesn't know anything about kernel-level overhead or activity in the > stats collector. (Hm, might be able to measure it in oprofile > though...)
I spent some time with oprofile and couldn't muster any evidence suggesting that this was accounting for more than 1% or so of total runtime. So for the moment I'll leave it alone. It might eventually become worth worrying about, though. The thing I saw as being more interesting than the tabstat overhead is that the planner does RelationGetNumberOfBlocks (ie, an lseek kernel call) on every child rel ... and would do it on every index of every child rel, too, if the example had any. It would be nice if we could postpone all of the work of get_relation_info() until after we've checked for constraint exclusion. This looks like it'd require some nontrivial refactoring though --- in particular, I'm not sure how we'd handle the total_table_pages calculation. If you're satisfied with the performance as it now stands, let's leave this for the maybe-do-someday list. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend