Re: FUNC_MAX_ARGS benchmarks - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: FUNC_MAX_ARGS benchmarks
Date
Msg-id 200208102321.g7ANLHs11473@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  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
OK, seems we have not come to a decision yet on this.

Do we have agreement to increate FUNC_MAX_ARGS to 32?

NAMEDATALEN will be 64 or 128 in 7.3.  At this point, we better decide
which one we prefer.

The conservative approach would be to go for 64 and perhaps increase it
again in 7.4 after we get feedback and real-world usage.  If we go to
128, we will have trouble decreasing it if there are performance
problems.

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

Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
> >> 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?
> 
> > Hmmm -- didn't Neil do some kind of test that had different results, 
> > i.e. not much performance difference?
> 
> Well, one person had reported a 10% slowdown in pgbench, but Neil saw
> a 10% speedup.  Given the well-known difficulty of getting any
> reproducible numbers out of pgbench, I don't trust either number very
> far; but unless some other folk are willing to repeat the experiment
> I think we can only conclude that pgbench isn't affected much by
> NAMEDATALEN.
> 
> > I wonder if the large number of 
> > DDL commands in installcheck doesn't skew the results against longer 
> > NAMEDATALEN compared to other benchmarks?
> 
> Depends on what you consider skewed, I suppose.  pgbench touches only a
> very small number of relations, and starts no new backends over the
> length of its run, thus everything gets cached and stays cached.  At
> best I'd consider it an existence proof that some applications won't be
> hurt.
> 
> Do you have another application you'd consider a more representative
> benchmark?
> 
>             regards, tom lane
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Rod Taylor
Date:
Subject: Re: AnonCVS woes
Next
From: Tom Lane
Date:
Subject: Re: FUNC_MAX_ARGS benchmarks