Re: FUNC_MAX_ARGS benchmarks
От | Dave Page |
---|---|
Тема | Re: FUNC_MAX_ARGS benchmarks |
Дата | |
Msg-id | D85C66DA59BA044EB96AB9683819CF6101515F@dogbert.vale-housing.co.uk обсуждение исходный текст |
Ответ на | FUNC_MAX_ARGS benchmarks (nconway@klamath.dyndns.org (Neil Conway)) |
Список | pgsql-hackers |
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: 05 August 2002 04:56 > To: Joe Conway > Cc: Bruce Momjian; Thomas Lockhart; Neil Conway; PostgreSQL Hackers > Subject: Re: [HACKERS] FUNC_MAX_ARGS benchmarks > > > Joe Conway <mail@joeconway.com> writes: > > These are all with FUNC_MAX_ARGS = 16. > > > #define NAMEDATALEN 32 > > 2.7M /opt/data/pgsql/data/base/1 > > > #define NAMEDATALEN 64 > > 3.0M /opt/data/pgsql/data/base/1 > > > #define NAMEDATALEN 128 > > 3.8M /opt/data/pgsql/data/base/1 > > Based on Joe's numbers, I'm kind of thinking that we should > go for FUNC_MAX_ARGS=32 and NAMEDATALEN=64 as defaults in 7.3. > > Although NAMEDATALEN=128 would be needed for full SQL > compliance, the space penalty seems severe. I'm thinking we > should back off until someone wants to do the legwork needed > to make the name type be truly variable-length. > > Comments? In Joe's last test he had only about 2Mb growth per db (I guess this would not be the case had he used the name type in some of his tables). I would rather lose a measly few Mb and be standards compliant myself. $0.02 Regards, Dave.
В списке pgsql-hackers по дате отправления: