Re: FUNC_MAX_ARGS benchmarks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, 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-05 23:46:03
Message-ID: 28486.1028591163@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joe Conway <mail(at)joeconway(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2002-08-06 00:45:33 Re: FUNC_MAX_ARGS benchmarks
Previous Message Joe Conway 2002-08-05 23:08:40 Re: FUNC_MAX_ARGS benchmarks