Re: FUNC_MAX_ARGS benchmarks - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: FUNC_MAX_ARGS benchmarks
Date
Msg-id 200208060610.g766AQa13441@candle.pha.pa.us
Whole thread Raw
In response to Re: FUNC_MAX_ARGS benchmarks  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: FUNC_MAX_ARGS benchmarks  ("Nigel J. Andrews" <nandrews@investsystems.co.uk>)
List 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@postgresql.org
> 

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


pgsql-hackers by date:

Previous
From: "Christopher Kings-Lynne"
Date:
Subject: Re: New manual chapters
Next
From: Joe Conway
Date:
Subject: Re: FUNC_MAX_ARGS benchmarks