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