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.
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 |