Re: [PATCHES] [SQL] 16 parameter limit - Mailing list pgsql-hackers

From Neil Conway
Subject Re: [PATCHES] [SQL] 16 parameter limit
Date
Msg-id 20020415234235.7836bcf5.nconway@klamath.dyndns.org
Whole thread Raw
In response to Re: [PATCHES] [SQL] 16 parameter limit  (Alvaro Herrera <alvherre@atentus.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [PATCHES] [SQL] 16 parameter limit
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] [SQL] 16 parameter limit