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
