Thanks for the review! On Thu, Dec 12, 2024 at 12:53 AM Jelte Fennema-Nio <postg...@jeltef.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.
v05-0001-Add-pipelining-support-in-psql.patch
Description: Binary data
