Re: FUNC_MAX_ARGS benchmarks

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Joe Conway <mail(at)joeconway(dot)com>, Thomas Lockhart <lockhart(at)fourpalms(dot)org>, Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FUNC_MAX_ARGS benchmarks
Date: 2002-08-06 15:02:16
Message-ID: 1028646136.12188.3.camel@taru.tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2002-08-06 at 15:36, Tom Lane wrote:
> "Nigel J. Andrews" <nandrews(at)investsystems(dot)co(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Bartunov 2002-08-06 15:26:59 Re: CVS sources doesn't compiles
Previous Message Tom Lane 2002-08-06 15:01:28 Re: Better handling of parse errors