Another thing I noticed while looking at Gavin Hamill's test case is
that according to gprof, it's spending a remarkably large fraction of
its time in lookupParam():
Each sample counts as 0.01 seconds. % cumulative self self total time seconds
seconds calls s/call s/call name 13.87 20.28 20.28 3219733 0.00 0.00 lookupParam11.20
36.65 16.37 6128411 0.00 0.00 LWLockAcquire 8.86 49.60 12.95 6128574 0.00 0.00
LWLockRelease5.73 57.97 8.37 12654786 0.00 0.00 _bt_compare 5.60 66.15 8.18 2746677 0.00
0.00 PinBuffer 5.53 74.24 8.09 669262 0.00 0.00 s_lock 5.17 81.80 7.56 1380848 0.00
0.00 slot_deform_tuple 3.72 87.24 5.44 2750944 0.00 0.00 UnpinBuffer 3.27 92.02 4.78
2772808 0.00 0.00 hash_search 2.23 95.28 3.26 16960980 0.00 0.00 FunctionCall2
I don't recall ever seeing this function high in a profile before, but
in a complex function it's not so implausible as all that. lookupParam
works by linear search, which means that accessing N different
parameters will take O(N^2) time.
AFAICS the only reason for a linear search is that the params.c code
still has vestigial support for named rather than numbered Params.
That's been dead code since the system left Berkeley, and I don't know
of anything on the horizon that would make us want to revive it.
(In places where we'd support named params, it'd make more sense to
reduce the names to numbers before runtime anyway.)
So I'm thinking about simplifying the ParamListInfo data structure
down to a straight array indexed directly by parameter number.
Anyone have a problem with that?
regards, tom lane