Re: FUNC_MAX_ARGS benchmarks - Mailing list pgsql-hackers

From Joe Conway
Subject Re: FUNC_MAX_ARGS benchmarks
Date
Msg-id 3D4E1D02.6010305@joeconway.com
Whole thread Raw
In response to Re: FUNC_MAX_ARGS benchmarks  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: FUNC_MAX_ARGS benchmarks  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Joe Conway wrote:
> But is the space wasted really never more than a few MB's, even if the 
> database itself is say 1 GB? If so, and if the speed penalty is small to 
> non-existent, I'd rather be spec compliant. That way nobody has a good 
> basis for complaining ;-)
> 
> I guess I'll try another test with a larger data-set.
> 

Starting with pg_dumpall file at 138M.


#define INDEX_MAX_KEYS        16
#define FUNC_MAX_ARGS        INDEX_MAX_KEYS
#define NAMEDATALEN 32
du -h --max-depth=1 /opt/data/pgsql/data/base/
2.7M    /opt/data/pgsql/data/base/1
2.7M    /opt/data/pgsql/data/base/16862
119M    /opt/data/pgsql/data/base/16863
3.1M    /opt/data/pgsql/data/base/696496
3.1M    /opt/data/pgsql/data/base/696623
3.1M    /opt/data/pgsql/data/base/696750
2.8M    /opt/data/pgsql/data/base/696877
2.8M    /opt/data/pgsql/data/base/696889
2.8M    /opt/data/pgsql/data/base/696901
2.8M    /opt/data/pgsql/data/base/696912
18M     /opt/data/pgsql/data/base/696924
3.0M    /opt/data/pgsql/data/base/878966
2.7M    /opt/data/pgsql/data/base/881056
2.7M    /opt/data/pgsql/data/base/881075
2.8M    /opt/data/pgsql/data/base/881078
3.1M    /opt/data/pgsql/data/base/881093
3.1M    /opt/data/pgsql/data/base/881225
2.8M    /opt/data/pgsql/data/base/881604
3.3M    /opt/data/pgsql/data/base/881620
31M     /opt/data/pgsql/data/base/881807
31M     /opt/data/pgsql/data/base/1031939
32M     /opt/data/pgsql/data/base/1181250
31M     /opt/data/pgsql/data/base/1332676
309M    /opt/data/pgsql/data/base


#define INDEX_MAX_KEYS        32
#define FUNC_MAX_ARGS        INDEX_MAX_KEYS
#define NAMEDATALEN 128
du -h --max-depth=1 /opt/data/pgsql/data/base/
4.1M    /opt/data/pgsql/data/base/1
4.1M    /opt/data/pgsql/data/base/16863
121M    /opt/data/pgsql/data/base/16864
4.6M    /opt/data/pgsql/data/base/696497
4.6M    /opt/data/pgsql/data/base/696624
4.6M    /opt/data/pgsql/data/base/696751
4.2M    /opt/data/pgsql/data/base/696878
4.2M    /opt/data/pgsql/data/base/696890
4.2M    /opt/data/pgsql/data/base/696902
4.2M    /opt/data/pgsql/data/base/696913
20M     /opt/data/pgsql/data/base/696925
4.5M    /opt/data/pgsql/data/base/878967
4.2M    /opt/data/pgsql/data/base/881057
4.1M    /opt/data/pgsql/data/base/881076
4.2M    /opt/data/pgsql/data/base/881079
4.7M    /opt/data/pgsql/data/base/881094
4.7M    /opt/data/pgsql/data/base/881226
4.2M    /opt/data/pgsql/data/base/881605
4.9M    /opt/data/pgsql/data/base/881621
33M     /opt/data/pgsql/data/base/881808
33M     /opt/data/pgsql/data/base/1031940
33M     /opt/data/pgsql/data/base/1181251
33M     /opt/data/pgsql/data/base/1332677
343M    /opt/data/pgsql/data/base

So the 119MB database only grows to 121MB. In fact, each of the > 10MB 
databases seems to grow only about 2MB. Based on this, I'd go with:

#define INDEX_MAX_KEYS        32
#define FUNC_MAX_ARGS        INDEX_MAX_KEYS
#define NAMEDATALEN 128

and take spec compliance.

Joe



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: FUNC_MAX_ARGS benchmarks
Next
From: Florian Weimer
Date:
Subject: Re: [COMMITTERS] pgsql-server/src