Re: 2018-03 Commitfest Summary (Andres #1)

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.