Re: FUNC_MAX_ARGS benchmarks - Mailing list pgsql-hackers

From Dave Page
Subject Re: FUNC_MAX_ARGS benchmarks
Date
Msg-id D85C66DA59BA044EB96AB9683819CF6101515F@dogbert.vale-housing.co.uk
Whole thread Raw
In response to FUNC_MAX_ARGS benchmarks  (nconway@klamath.dyndns.org (Neil Conway))
List 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 by date:

Previous
From: Florian Weimer
Date:
Subject: Re: [COMMITTERS] pgsql-server/src
Next
From: Neil Conway
Date:
Subject: Re: Wacky OID idea