Re: Open 7.3 items

From: Rod Taylor <rbt(at)zort(dot)ca>
To: Stephen Deasey <stephen(at)bollocks(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, nconway(at)klamath(dot)dyndns(dot)org
Subject: Re: Open 7.3 items
Date: 2002-08-02 18:09:58
Message-ID: 1028311799.10895.32.camel@jester
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2002-08-01 at 00:42, Stephen Deasey wrote:
> Neil Conway said:
> >> FUNC_MAX_ARGS - disk/performance penalty for increase, 24, 32?
> >
> >Until someone takes the time to determine what the performance
> >implications of this change will be, I don't think we should
> >change this. Given that no one has done any testing, I'm not
> >convinced that there's a lot of demand for this anyway.
>
>
> There's a huge demand for this from the folks involved with OpenACS.
> Already many of the functions have run up against the 16 column limit.
> Overloading is an ugly cludge for some functions which have 'default'
> args, but it's not a complete solution.
>
> Not that it has proven to be slower, but if it were but the difference
> was small, I'd say that forcing a recomplile to eek out a little extra
> performance is better than forcing it to make code work in the first
> place.
>
> 32 args, please!

32 at a bare minimum. Someone needs to dig out what the problem is and
make the cost increase with length. > 128 args is easily feasibly given
some Oracle systems I've seen -- DB functions as middleware.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Sullivan 2002-08-02 18:11:09 Re: [HACKERS] []performance issues
Previous Message Rod Taylor 2002-08-02 18:08:02 Re: [HACKERS] []performance issues