| From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Joe Conway <mail(at)joeconway(dot)com>, Thomas Lockhart <lockhart(at)fourpalms(dot)org>, Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: FUNC_MAX_ARGS benchmarks |
| Date: | 2002-08-05 05:21:37 |
| Message-ID: | 200208050521.g755Lc810381@candle.pha.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)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.
I prefer 64 for NAMEDATALEN myself. Standards compliance is nice, but
realistically it seems a shame to waste so much space on an excessive
length that will never be used.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Kings-Lynne | 2002-08-05 05:27:58 | Wacky OID idea |
| Previous Message | Greg Copeland | 2002-08-05 04:21:38 | Re: PITR, checkpoint, and local relations |