Thread: Re: [PATCHES] [SQL] 16 parameter limit

Tom Lane writes:

> Neil Conway <nconway@klamath.dyndns.org> writes:
> > My vote is to set the default # of function args to some
> > reasonable default (32 sounds good), and leave it at that.
>
> Bear in mind that s/32/16/ gives you the exact state of the discussion
> when we raised the limit from 8 to 16 ;-)

How about this:  We store the first 16 parameters in some fixed array for
fast access like now, and when you have more than 16 then 17 and beyond
get stored in some variable array in pg_proc.  This way procedures with
few arguments don't lose any performance but we could support an
"infinite" number of parameters easily.  It sounds kind of dumb, but
without some sort of break out of the fixed storage scheme we'll have this
argument forever.

-- 
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:
> How about this:  We store the first 16 parameters in some fixed array for
> fast access like now, and when you have more than 16 then 17 and beyond
> get stored in some variable array in pg_proc.

<<itch>>  What's this going to cost us in the function lookup code paths?

If we can do it with little or no performance cost (at least for the
"normal case" of fewer-than-N parameters) then I'm all ears.
        regards, tom lane

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > How about this:  We store the first 16 parameters in some fixed array for
> > fast access like now, and when you have more than 16 then 17 and beyond
> > get stored in some variable array in pg_proc.
> 
> <<itch>>  What's this going to cost us in the function lookup code paths?
> 
> If we can do it with little or no performance cost (at least for the
> "normal case" of fewer-than-N parameters) then I'm all ears.

OK, I have an idea.  Tom, didn't you just add code that allows the cache
to return multiple rows for a lookup?  I think you did it for schemas.

What if we lookup on the first 16 params, then look at every matching
hit if there are more than 16 params supplied?  Another idea would be to
hash the function arg types and look that up rather than looking for
exact matches of oidvector.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

On Tue, 2002-04-16 at 07:01, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > How about this:  We store the first 16 parameters in some fixed array for
> > fast access like now, and when you have more than 16 then 17 and beyond
> > get stored in some variable array in pg_proc.
> 
> <<itch>>  What's this going to cost us in the function lookup code paths?
> 
> If we can do it with little or no performance cost (at least for the
> "normal case" of fewer-than-N parameters) then I'm all ears.

Perhaps we could use the 16-th element as an indicator of 16-or-more
args. If it is 0 then there are <= 15 args if it is something else, then
this something else is hash of extra argument types that need to be
looked up separately. 

Of course we will need some way of resolving multiple hash matches.

--------------
Hannu