| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk> |
| Cc: | 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 13:36:48 |
| Message-ID: | 12291.1028641008@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"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. 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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-08-06 13:40:40 | Re: contrib/ltree for 7.2 or 7.3 ? |
| Previous Message | Oleg Bartunov | 2002-08-06 13:03:51 | CVS sources doesn't compiles |