Обсуждение: 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. +