Re: Open 7.3 items - Mailing list pgsql-hackers

From Rod Taylor
Subject Re: Open 7.3 items
Date
Msg-id 1028311799.10895.32.camel@jester
Whole thread Raw
In response to Re: Open 7.3 items  (Stephen Deasey <stephen@bollocks.net>)
List 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.



pgsql-hackers by date:

Previous
From: Andrew Sullivan
Date:
Subject: Re: FUNC_MAX_ARGS benchmarks
Next
From: Thomas Lockhart
Date:
Subject: Re: WAL file location