Re: FUNC_MAX_ARGS benchmarks - Mailing list pgsql-hackers

From Nigel J. Andrews
Subject Re: FUNC_MAX_ARGS benchmarks
Date
Msg-id Pine.LNX.4.21.0208061044170.3235-100000@ponder.fairway2k.co.uk
Whole thread Raw
In response to Re: FUNC_MAX_ARGS benchmarks  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: FUNC_MAX_ARGS benchmarks  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 6 Aug 2002, Bruce Momjian wrote:

> 
> As long as we allocate the full length for the funcarg and name types,
> we are going to have performance/space issues with increasing them,
> especially since we are looking at doubling or quadrupling those values.
> 
> [snip]
> 
> I think funcargs of 32 and name of 64 is the way to go for 7.3.  If we
> find we need longer names or we find we can make them variable length,
> we can revisit the issue.  However, variable length has a performance
> cost as well, so it is not certain we will ever make them variable
> length.

I was thinking of looking at turning names to varchars/text in order to test
the performance hit [in the first instance]. However doing a
 find . -name \*\.\[ch\] | xargs grep NAMEDATALEN | wc -l

gives 185 hits and some of those are setting other macros. It seems to me there
is a fair amount of work involved in just getting variable length names into
the system so that they can be tested.



-- 
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants



pgsql-hackers by date:

Previous
From: "Nigel J. Andrews"
Date:
Subject: Re: Proposal for psql wildcarding behavior w/schemas
Next
From: Oleg Bartunov
Date:
Subject: CVS sources doesn't compiles