From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com> |
Cc: | Daniel Verite <daniel(at)manitou-mail(dot)org>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add Pipelining support in psql |
Date: | 2025-03-04 23:25:34 |
Message-ID: | Z8eL7rdhDLndyvuS@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 04, 2025 at 06:37:09PM +0100, Anthonin Bonnefoy wrote:
> I do see the idea to make it easier to convert existing scripts into
> using pipelining. The main focus of the initial implementation was
> more on protocol regression tests with psql, so that's not necessarily
> something I had in mind. I have some reservation as it will push all
> parameters in the query string which may not be the desired behaviour.
> But on the other hand, if it is to convert existing psql scripts, then
> everything was already pushed as simple queries. Plus, this is similar
> to what pgbench is doing when using -Mextended or -Mprepared.
Hmm. Simplicity is tempting here because we know the status of the
pipeline when sending the query. If we do something like what you are
suggesting here, do we actually need the \sendpipeline at all? We
should still prevent \g, \gx and others from running in a pipeline
because of the format argument raised by Daniel so as we restrict the
use of meta-commands that can manipulate the output format, right?
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Melanie Plageman | 2025-03-04 23:25:42 | Re: Log connection establishment timings |
Previous Message | Michael Paquier | 2025-03-04 23:23:32 | Re: Refactoring postmaster's code to cleanup after child exit |