Re: FUNC_MAX_ARGS benchmarks

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: FUNC_MAX_ARGS benchmarks
Дата
Msg-id 28486.1028591163@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: FUNC_MAX_ARGS benchmarks  (Joe Conway <mail@joeconway.com>)
Ответы Re: FUNC_MAX_ARGS benchmarks
Список 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 по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: FUNC_MAX_ARGS benchmarks
Следующее
От: Joe Conway
Дата:
Сообщение: Re: FUNC_MAX_ARGS benchmarks