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

From Michael Paquier
Subject Re: PATCH: Batch/pipelining support for libpq
Date
Msg-id CAB7nPqSDjmw4WmHDAWe_U3h-V32HYTojynuuMpuGRZN9YGKCzA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] PATCH: Batch/pipelining support for libpq  (Vaishnavi Prabakaran <vaishnaviprabakaran@gmail.com>)
Responses Re: PATCH: Batch/pipelining support for libpq  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
On Sat, Mar 25, 2017 at 9:50 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
> I'm fairly confident that I overlooked single row mode entirely in the
> original patch, though it's long enough ago that it's hard for me to
> remember exactly.
>
> I don't really have much of an opinion on the best handling of it.
>
> I would expect to be setting single-row mode just before I requested
> the *result* from the next pending query, since it relates to result
> processing rather than query dispatch. But that's about all the
> opinion I have here.

Yeah, I think that it makes sense to allow users to switch to single
row mode before requesting a result in the queue. It seems to me that
this should also be effective only during the fetching of one single
result set. When the client moves on to the next item in the queue we
should make necessary again a call to PQsetSingleRowMode().

Regarding the patch, I have spotted the following things in the last version:
- src/test/modules/Makefile should include test_libpq.
- Regression tests from 0002 are failing:
ok 1 - testlibpqbatch disallowed_in_batch
ok 2 - testlibpqbatch simple_batch
ok 3 - testlibpqbatch multi_batch
ok 4 - testlibpqbatch batch_abort
ok 5 - testlibpqbatch timings
not ok 6 - testlibpqbatch copyfailure
-- 
Michael



pgsql-hackers by date:

Previous
From: Rafia Sabih
Date:
Subject: Re: Parallel bitmap heap scan
Next
From: Amit Khandekar
Date:
Subject: Re: UPDATE of partition key