Thread: Simplifying Param lookups
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
Tom Lane wrote: > 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? No problem, sounds smart. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +