Re: FUNC_MAX_ARGS benchmarks
Hannu Krosing <hannu@tm.ee>
From: Hannu Krosing <hannu@tm.ee>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Nigel J. Andrews" <nandrews@investsystems.co.uk>, Bruce Momjian <pgman@candle.pha.pa.us>, Joe Conway <mail@joeconway.com>, Thomas Lockhart <lockhart@fourpalms.org>, Neil Conway <nconway@klamath.dyndns.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2002-08-06T15:02:16Z
Lists: pgsql-hackers
On Tue, 2002-08-06 at 15:36, Tom Lane wrote: > "Nigel J. Andrews" <nandrews@investsystems.co.uk> writes: > > 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. > > And that is not even the tip of the iceberg. The real reason that NAME > is fixed-length is so that it can be accessed as a member of a C > structure. I'm not pretending to know anything about it, but can't this be made into a pointer that is accessed as a member of a C structure. This should not need rearranging the field order. And if we were lucky enough, then change from char[32] to char* will be invisible for most places that use it. > Moving NAME into the variable-length category would make it > much more painful to access than it is now, and would require > rearranging the field order in every system catalog that has a name field. From what I remember the main concern was lack of support for varlen types in cache manager (whatever it means) ? --------------- Hannu