Date: Mon, 15 Apr 2002 23:42:35 -0400
From: Neil Conway <nconway@klamath.dyndns.org>
To: "Alvaro Herrera" <alvherre@atentus.com>
Cc: rbt@zort.ca, pgsql-hackers@postgresql.org
Subject: Re: [PATCHES] [SQL] 16 parameter limit
Message-Id: <20020415234235.7836bcf5.nconway@klamath.dyndns.org>
In-Reply-To: <20020415233404.57d7fc01.alvherre@atentus.com>
References: <200204160258.g3G2wpG01075@candle.pha.pa.us>
	<0a9401c1e4f5$8f2ac5b0$8001a8c0@jester>
	<20020415233404.57d7fc01.alvherre@atentus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

On Mon, 15 Apr 2002 23:34:04 -0400
"Alvaro Herrera" <alvherre@atentus.com> wrote:
> En Mon, 15 Apr 2002 23:19:45 -0400
> "Rod Taylor" <rbt@zort.ca> escribió:
> 
> > On the note of NAMEDATALEN, a view in the INFORMATION_SCHEMA
> > definition is exactly 2 characters over the current limit.
> > 
> > ADMINISTRABLE_ROLE_AUTHORIZATIONS
> > 
> > Not that it's a great reason, but it isn't a bad one for increasing
> > the limit ;)
> 
> http://archives.postgresql.org/pgsql-general/2002-01/msg00939.php
> 
> (Tom Lane says both SQL92 and SQL99 specify 128 as the maximun
> identifier length)
> 
> Anyway, how does one measure the perfomance impact of such a change?
> By merely changing the constant definition, or also by actually using
> long identifiers?

Name values are stored NULL-padded up to NAMEDATALEN bytes, so
there is no need to actually use long identifiers, just change
the value of NAMEDATALEN, recompile and run some benchmarks
(perhaps OSDB? http://osdb.sf.net).

If you do decide to run some benchmarks (and some more data
would be good), please use the current CVS code. I sent in a
patch a little while ago that should somewhat reduce the
penalty for increasing NAMEDATALEN.

Cheers,

Neil

-- 
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC