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
|
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: