Re: pgbench more operators & functions

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: pgbench more operators & functions
Дата
Msg-id alpine.DEB.2.20.1610051832050.20888@lancre
обсуждение исходный текст
Ответ на Re: pgbench more operators & functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hello Tom,

>> (2) The benchmark specification requires the client application to get
>> hold of query results, which are currently discarded by pgbench, so
>> pgbench does not really comply. I have submitted a patch to do that, see:
>
> I find this completely bogus.  The data is delivered to the client,
> ie it's inside the pgbench process.

Hmmm... It is delivered to libpq, and the client discards it... In a 
benchmarking context I think that this is not exactly the same:

For instance, one could implement a library protocol that would tell that 
the result is ready without actually transfering the result, getting a 
slight benefit by not doing so.

In order to avoid that kind of doubtful optimization, the benchmark 
requires that the final balance is returned to the "test driver", which is 
the client application, and not some subsystem linked to the database. I 
think that this is a pretty sensible requirement.

Moreover, the teller's branch must be used in some case, not sure how to 
do that without getting this value out anyway...

> What's the grounds for arguing that something else has to happen to it?

In my view the "ground" is the benchmarking specification which wants to 
ensure that the tester/implementers/vendors cannot cheat to get better 
than deserved performance results...

-- 
Fabien.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: WIP: Secure Transport support as OpenSSL alternative on macOS
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Hash Indexes