Re: FUNC_MAX_ARGS benchmarks

Tom Lane wrote:
> 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.

FWIW, I reran the speed benchmark (select 2+2+2...) with 
FUNC_MAX_ARGS=32 and NAMEDATALEN=128 and still got 49 seconds, i.e. 
NAMEDATALEN=128 didn't impact performance of that particular test.

The results were as follows:
INDEX_MAX_KEYS    16    32      64     128
                 -----+-------+------+--------
Time in seconds   48    49      51      55
                       ^^^^^^^^
                       reran with NAMEDATALEN=128, same result

What will the impact be on a medium to large production database? In 
other words, is the bloat strictly to the system catalogs based on how 
extensive your database schema (bad choice of words now, but I don't 
know a better term for this) is? Or will the bloat scale with the size 
of the database including data?

Joe