Re: FUNC_MAX_ARGS benchmarks - Mailing list pgsql-hackers

From Tom Lane
Subject Re: FUNC_MAX_ARGS benchmarks
Date
Msg-id 28486.1028591163@sss.pgh.pa.us
Whole thread Raw
In response to Re: FUNC_MAX_ARGS benchmarks  (Joe Conway <mail@joeconway.com>)
Responses Re: FUNC_MAX_ARGS benchmarks  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: FUNC_MAX_ARGS benchmarks
Next
From: Joe Conway
Date:
Subject: Re: FUNC_MAX_ARGS benchmarks