On Sun, Mar 27, 2005 at 03:41:08PM -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> > On Sun, Mar 27, 2005 at 12:44:41PM -0500, Tom Lane wrote:
> >> I've been toying with the idea of converting the oidvector and
> >> int2vector datatypes from fixed-width arrays to variable-length;
> >> that is, stick a varlena length word on the front and store only
> >> pronargs or indnatts entries instead of a fixed number.
>
> > This mean that it would be possible to set FUNC_MAX_ARGS much higher
> > without performance loss, right? That alone sounds like a big win to
> > me.
>
> It wouldn't cost anything in terms of disk space. I'm not sure about
> performance implications --- there are a lot of MemSets floating around
> that zero FUNC_MAX_ARGS worth of space, and I'm unsure if any of them
> are in performance-critical paths. Atsushi Ogawa got the most critical
> ones recently, though.
>
> Very likely we could kick it up to 100 or so without feeling any pain;
> how high were you thinking?
I used to see people asking to raise it to 64 or so. Not sure if it
would be useful to go higher than that ... much less now that we have
full-fledged support for row types.
I see 93 appearances of FUNC_MAX_ARGS in the code. There are 20 MemSet;
the only one of them that appears to be used regularly seems to be the
one in ParseFuncOrColumn; the rest are in FooCreate() or routines
thereof.
There are 3 memcpys, two of them are used regularly (inline_function,
get_func_signature). The other one is fetch_fp_info, which is used only
in dealing with PQfn().
(This info brought to you courtesy of cscope)
--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"I love the Postgres community. It's all about doing things _properly_. :-)"
(David Garamond)
