Hello Andres,
Thanks for managing this CF.
- pgbench - allow to store query results into variables RFC, has been worked on for a while. Patch doesn't look 100% there, but not that far away from it either.
What would be missing to look 100% there?
A bit concerned that we're turning pgbench into a kitchen sink.
I do not understand "kitchen sink" expression in this context, and your general concerns about pgbench in various comments in your message.
Currently pgbench this a one-way thing: one can send queries but there is no way to manipulate the result and act upon it, which limits the kind of scenario that can be implemented to unconditional data-independent transactions.
This makes the tool only half-backed thing: it provides a lot of detailed logging and reporting features, which are definitely useful to any benchmarking, but then you cannot write anything useful with it, which is just too bad.
So this setting-variable-from-query patch goes with having boolean expressions (already committed), having conditions (\if in the queue), improving the available functions (eg hashes, in the queue)... so that existing, data-dependent, realistic benchmarks can be implemented, and benefit for the great performance data collection provided by the tool.
- pgbench - another attempt at tap test for time-related options NR, another attempt at adding tests. I'd personally boot this to the next fest, it's definitely not critical.
Indeed. The main point is to improve code coverage.
- pgbench - add \if support RFC. I'm personally unconvinced we want this. Others on the thread seem unsure as well.
See above.
- General purpose hashing func in pgbench RFC. Does mostly look ready, although I'm not sure the docs are at the right level of detail. I've similar concerns to earlier pgbench patches adding new operators, even though to a bit lower degree.
See above. Such simple functions are used in actual benchmarks.
- pgbench - test whether a variable exists NR. Submitted first time mid February. Quoting from author: "Note that it is not really that useful for benchmarking, although it does not harm." I'd reject or boot.
As already said, the motivation is that it is a preparation for a (much) larger patch which would move pgbench expressions to fe utils and use them in "psql". If you do not want the final feature, there is no point in preparing, and you can reject it. However ISTM that the final feature is desired, hence the submission of this necessary step.
-- Fabien.
