Re: FUNC_MAX_ARGS benchmarks

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Thomas Lockhart <lockhart(at)fourpalms(dot)org>, Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FUNC_MAX_ARGS benchmarks
Date: 2002-08-06 06:10:25
Message-ID: 200208060610.g766AQa13441@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


As long as we allocate the full length for the funcarg and name types,
we are going to have performance/space issues with increasing them,
especially since we are looking at doubling or quadrupling those values.

You can say that the test below isn't a representative benchmark, but I
am sure it is typical of _some_ of our users, so it may still be a
significant test. We don't get good benchmark numbers by accident. It
is this type of analysis that keeps us sharp.

I think funcargs of 32 and name of 64 is the way to go for 7.3. If we
find we need longer names or we find we can make them variable length,
we can revisit the issue. However, variable length has a performance
cost as well, so it is not certain we will ever make them variable
length.

---------------------------------------------------------------------------

Tom Lane wrote:
> Well, in fact it's not just a question of disk space.
>
> The following numbers are stats for total elapsed time of "make
> installcheck" over ten trials:
>
> NAMEDATALEN = 32, FUNC_MAX_ARGS = 16
>
> min | max | avg | stddev
> -------+-------+--------+-------------------
> 25.59 | 27.61 | 26.612 | 0.637003401351409
>
> NAMEDATALEN = 64, FUNC_MAX_ARGS = 32
>
> min | max | avg | stddev
> -------+-------+--------+-----------------
> 26.32 | 29.27 | 27.415 | 1.0337982824947
>
> NAMEDATALEN = 128, FUNC_MAX_ARGS = 32
>
> min | max | avg | stddev
> -------+-------+--------+------------------
> 27.44 | 30.79 | 29.603 | 1.26148105195622
>
> I'm not sure about the trend of increasing standard deviation --- that
> may reflect more disk I/O being done, and perhaps more checkpoints
> occurring during the test. But in any case it's clear that there's a
> nontrivial runtime cost here. Does a 10% slowdown bother you?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2002-08-06 06:20:24 Re: FUNC_MAX_ARGS benchmarks
Previous Message Christopher Kings-Lynne 2002-08-06 06:02:53 Re: New manual chapters