| From: | Matthieu Garrigues <matthieu(dot)garrigues(at)gmail(dot)com> |
|---|---|
| To: | Dave Cramer <davecramer(at)postgres(dot)rocks> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PATCH: Batch/pipelining support for libpq |
| Date: | 2020-09-21 13:41:13 |
| Message-ID: | CAJkzx4S+hwDpJm95HT8e-m3RXfNECgBKrdiR1pN6wu8B2Xy8cA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Matthieu Garrigues
On Mon, Sep 21, 2020 at 3:09 PM Dave Cramer <davecramer(at)postgres(dot)rocks> wrote:
>>
> There was a comment upthread a while back that people should look at the comments made in https://www.postgresql.org/message-id/20180322.211148.187821341.horiguchi.kyotaro%40lab.ntt.co.jp by Horiguchi-San.
>
> From what I can tell this has not been addressed. The one big thing is the use of PQbatchProcessQueue vs just putting it in PQgetResult.
>
> The argument is that adding PQbatchProcessQueue is unnecessary and just adds another step. Looking at this, it seems like putting this inside PQgetResult would get my vote as it leaves the interface unchanged.
>
Ok. I'll merge PQbatchProcessQueue into PQgetResult. But just one
thing: I'll keep PQgetResult returning null between the result of two
batched query so the user
can know which result comes from which query.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2020-09-21 13:41:46 | Re: Command statistics system (cmdstats) |
| Previous Message | Dave Cramer | 2020-09-21 13:39:23 | Re: PATCH: Batch/pipelining support for libpq |