Re: Add Pipelining support in psql

Thanks for the review!

On Thu, Dec 12, 2024 at 12:53 AM Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:
> I think that new prompt is super useful, so useful in fact that I'd
> suggest linking to it from the \startpipeline docs.

Good point, I've added a paragraph with the link to the %P prompt.

> I do think that
> the wording in the docs could be a bit more precise:
> 1. The columns are not necessarily queries, they are messages or
> commands. i.e. \parse and \bind_named both count as 1, even though
> they form one query together.

Yeah, I wasn't super happy with the num_queries and wording. I've
renamed the prompt columns to piped_syncs, piped_commands and
pending_results and added more precision on what counts as a command.

> 2. messages not followed by \sync and \flushrequest, could very well
> already "be sent to the server" (if the client buffer got full, or in
> case of manual \flush). The main thing that \sync and \flushrequest do
> is make sure that the server actually sends its own result back, even
> if its buffer is not full yet.

I had the wrong assumptions on what was happening. I've changed the
definition of pending_results to: "pending_results is the number of
commands that were followed by either a \flushrequest or a
\syncpipeline, forcing the server to send the results that can be
retrieved with \getresults."

> The main feedback I have after playing around with this version is
> that I'd like to have a \getresult (without the s), to only get a
> single result. So that you can get results one by one, possibly
> interleaved with some other queries again.

\getresults was easier to implement since it was more or less the
current behaviour :). I didn't want to add a new meta-command just for
that (I feel like I'm already adding a lot of them) so I've added a
num_results parameter to \getresults. You should be able to use
\getresults 1 to get a single result. A sync response count as a
result.

> One thing I'm wondering is how useful the num_syncs count is in the
> pipeline prompt, since you never really wait for a sync.

With the addition of the num_results parameter for \getresults,
knowing the number of syncs becomes more useful when results are
consumed one by one.

> Regarding the usefulness of \flush. I agree it's not as useful as I
> thought, because indeed \getresults already flushes everything. But
> it's not completely useless either. The main way I was able to use it
> interactively in a somewhat interesting way was to send it after a
> long running query, and then while that's processing type up the next
> query after it.

I feel there's a large overlap between \flush and \flushrequest. On
the other hand, if people want to test the behaviour of pushing data
with and without a flush request message, then \flush can be useful.