Re: PATCH: Batch/pipelining support for libpq - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: PATCH: Batch/pipelining support for libpq
Date
Msg-id 20201118175134.GA30739@alvherre.pgsql
Whole thread Raw
In response to Re: PATCH: Batch/pipelining support for libpq  ("Daniel Verite" <daniel@manitou-mail.org>)
Responses Re: PATCH: Batch/pipelining support for libpq  ("Andres Freund" <andres@anarazel.de>)
Re: PATCH: Batch/pipelining support for libpq  ("Daniel Verite" <daniel@manitou-mail.org>)
List pgsql-hackers
On 2020-Nov-14, Daniel Verite wrote:

> The patch I posted in [1] was pretty simple, but at the time, query
> results were always discarded. Now that pgbench can instantiate
> variables from query results, a script can do:
>   select 1 as var \gset
>   select :var;
> This kind of sequence wouldn't work in batch mode since it
> sends queries before getting results of previous queries.
> 
> So maybe \gset should be rejected when inside a batch section.

Hah.

Hacking pgbench extensively is beyond what I'm willing to do for this
feature at this time.  Making \gset rejected in a batch section sounds
simple enough and supports \beginbatch et al sufficiently to compare
performance, so I'm OK with a patch that does that.  That'd be a small
extension to your previous patch, if I understand correctly.

If you or others want to send patches to extend batch support with
read-write tracking for variables, feel free, but I hereby declare that
I'm not taking immediate responsibility for getting them committed.




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Is postgres ready for 2038?
Next
From: Simon Riggs
Date:
Subject: Re: VACUUM (DISABLE_PAGE_SKIPPING on)