Re: pgbench more operators & functions - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench more operators & functions
Date
Msg-id alpine.DEB.2.20.1610051832050.20888@lancre
Whole thread Raw
In response to Re: pgbench more operators & functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: WIP: Secure Transport support as OpenSSL alternative on macOS
Next
From: Robert Haas
Date:
Subject: Re: Hash Indexes