Re: INDEX_MAX_KEYS to 64?

From: Joe Conway <mail(at)joeconway(dot)com>
To: Rod Taylor <rbt(at)rbt(dot)ca>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: INDEX_MAX_KEYS to 64?
Date: 2003-07-01 02:01:52
Message-ID: 3F00EB90.1090901@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Rod Taylor wrote:
> On Tue, 2003-07-01 at 01:25, Tom Lane wrote:
>>Not without evidence that it doesn't cause performance penalties.
>>ISTM we have been through this discussion recently, and concluded
>>that 32 was the place to set it.
>
> Yes, I was digging through that discussion. The test used shows a 4%
> difference between 32 and 64.
>
> do 100 times
> select 2+2+2+2+2+2+ ... iterated 9901 times

There was also this, on disk usage - about 25% penalty going from 32 to
64 (at least for small databases).

Joe Conway wrote:
> Tom Lane wrote:
>> Did you happen to make any notes about the disk space occupied by the
>> database? One thing I was worried about was the bloat that'd occur
>> in pg_proc, pg_index, and pg_proc_proname_args_nsp_index. Aside from
>> costing disk space, this would indirectly slow things down due to
>> more I/O to read these tables --- an effect that probably your test
>> couldn't measure, since it wasn't touching very many entries in any
>> of those tables.
>
>
> #define INDEX_MAX_KEYS 16
> #define FUNC_MAX_ARGS INDEX_MAX_KEYS
> 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
> 2.7M /opt/data/pgsql/data/base/16863
> 2.7M /opt/data/pgsql/data/base/16864
> 3.2M /opt/data/pgsql/data/base/16865
> 2.7M /opt/data/pgsql/data/base/16866
> 17M /opt/data/pgsql/data/base
>
> #define INDEX_MAX_KEYS 32
> #define FUNC_MAX_ARGS INDEX_MAX_KEYS
> du -h --max-depth=1 /opt/data/pgsql/data/base/
> 3.1M /opt/data/pgsql/data/base/1
> 3.1M /opt/data/pgsql/data/base/16862
> 3.1M /opt/data/pgsql/data/base/16863
> 3.1M /opt/data/pgsql/data/base/16864
> 3.6M /opt/data/pgsql/data/base/16865
> 3.1M /opt/data/pgsql/data/base/16866
> 19M /opt/data/pgsql/data/base
>
> #define INDEX_MAX_KEYS 64
> #define FUNC_MAX_ARGS INDEX_MAX_KEYS
> du -h --max-depth=1 /opt/data/pgsql/data/base/
> 3.9M /opt/data/pgsql/data/base/1
> 3.9M /opt/data/pgsql/data/base/16862
> 3.9M /opt/data/pgsql/data/base/16863
> 3.9M /opt/data/pgsql/data/base/16864
> 4.4M /opt/data/pgsql/data/base/16865
> 3.9M /opt/data/pgsql/data/base/16866
> 24M /opt/data/pgsql/data/base
>
> #define INDEX_MAX_KEYS 128
> #define FUNC_MAX_ARGS INDEX_MAX_KEYS
> du -h --max-depth=1 /opt/data/pgsql/data/base/
> 5.7M /opt/data/pgsql/data/base/1
> 5.7M /opt/data/pgsql/data/base/16862
> 5.7M /opt/data/pgsql/data/base/16863
> 5.7M /opt/data/pgsql/data/base/16864
> 6.3M /opt/data/pgsql/data/base/16865
> 5.7M /opt/data/pgsql/data/base/16866
> 35M /opt/data/pgsql/data/base
>

Here's the thread:
http://archives.postgresql.org/pgsql-hackers/2002-08/msg00258.php

Joe

Joe

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2003-07-01 02:15:29 Re: Missing array support
Previous Message Rod Taylor 2003-07-01 01:40:28 Re: INDEX_MAX_KEYS to 64?