Re: [PATCHES] [SQL] 16 parameter limit

Поиск
Список
Период
Сортировка
Искать

Re: [PATCHES] [SQL] 16 parameter limit

От:
"Rod Taylor" <rbt@zort.ca>
Дата:
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 ;)

--
Rod Taylor

> Are we staying at 16 as the default?   I personally think we can
> increase it to 32 with little penalty, and that we should increase
> NAMEDATALEN to 64.

Re: [PATCHES] [SQL] 16 parameter limit

От:
Alvaro Herrera <alvherre@atentus.com>
Дата:
En Mon, 15 Apr 2002 23:19:45 -0400
"Rod Taylor"  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? I can do that if it's of any help, for various values
perhaps.

-- 
Alvaro Herrera ()
"Las cosas son buenas o malas segun las hace nuestra opinion" (Lisias)

Re: [PATCHES] [SQL] 16 parameter limit

От:
Neil Conway <nconway@klamath.dyndns.org>
Дата:
On Mon, 15 Apr 2002 23:34:04 -0400
"Alvaro Herrera"  wrote:
> En Mon, 15 Apr 2002 23:19:45 -0400
> "Rod Taylor"  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 
PGP Key ID: DB3C29FC

Re: [PATCHES] [SQL] 16 parameter limit

От:
Bruce Momjian <pgman@candle.pha.pa.us>
Дата:
Alvaro Herrera wrote:
> (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? I can do that if it's of any help, for various values
> perhaps.

I think I would measure disk size change in a newly created database,
and run regression for various values.  That uses a lot of identifier
lookups.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610) 853-3000 +  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re: [PATCHES] [SQL] 16 parameter limit

От:
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Дата:
> > 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? I can do that if it's of any help, for various values
> > perhaps.
>
> I think I would measure disk size change in a newly created database,
> and run regression for various values.  That uses a lot of identifier
> lookups.

With schemas, maybe there'd be less name lookups and comparisons anyway,
since there's more reliance on oids instead of names?

Chris
FAQ