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. +