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. + ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
