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 lookupParam
11.20 36.65 16.37 6128411 0.00 0.00 LWLockAcquire
8.86 49.60 12.95 6128574 0.00 0.00 LWLockRelease
5.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
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
