Re: Time to drop old-style (V0) functions?

On Tue, Dec 20, 2016 at 8:44 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> Advanced Server uses 256, and we had a customer complain recently that
>> 256 wasn't high enough. So apparently the use case for functions with
>> ridiculous numbers of arguments isn't exactly 0.
>
> Well, there's a cost/benefit analysis involved here, as in a lot of
> other places. There's a lot of things one can conceive a use-case for,
> doesn't mean it's worth catering for all of them.

Clearly true.

>> I mean, there's no reason that we can't use dynamic allocation here.
>> If we put the first, say, 8 arguments in the FunctionCallInfoData
>> itself and then separately allocated space any extras, the structure
>> could be a lot smaller without needing an arbitrary limit on the
>> argument count.
>
> Except that that'll mean additional overhead during evaluation of
> function arguments, an overhead that everyone will have to pay. Suddenly
> you need two loops that fill in arguments, depending on their
> argument-number (i.e. additional branches in a thight spot). And not
> being able to pass the null bitmap via an register argument also costs
> everyone.

Well, I'm hoping there is a way to have a fast-path and a slow-path
without slowing things down too much. You're proposing something like
that anyway, because you're proposing to put the first two arguments
in actual function arguments and the rest someplace else. I wouldn't
be surprised if 99% of function calls had 2 arguments or less because
most people probably call functions mostly or entirely as operators
and even user-defined functions don't necessarily have lots of
arguments. But we wouldn't propose restricting all function calls to
2 arguments just so +(int4, int4) can be fast. There's clearly got to
be a slow path for calls with more than 2 arguments and, if that's the
case, I don't see why there can't be a really-slow path, perhaps
guarded by unlikely(), for cases involving more than 8 or 16 or
whatever. I find it really hard to believe that in 2016 that we can't
find a way to make simple things fast and complicated things possible.
Saying we can't make SQL-callable functions with large number of
arguments work feels to me like saying that we have to go back to
8-character filenames with 3-character extensions for efficiency - in
the 1980s, that argument might have held some water, but nobody buys
it any more. Human time is worth more than computer time, and humans
save time when programs don't impose inconveniently-small limits.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company