Re: FUNC_MAX_ARGS benchmarks

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.

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