Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?

From: "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?
Date: 2023-03-17 23:15:02
Message-ID: 20230317231502.msq7m3rhqxkc47tz@hjp.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 2023-03-16 11:52:47 +0100, Dominique Devienne wrote:
> On Thu, Mar 16, 2023 at 11:15 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> čt 16. 3. 2023 v 9:55 odesílatel Dominique Devienne <ddevienne(at)gmail(dot)com>
> napsal:
> That's a nice way to put it Pavel.
> And to have it both ways, use COPY in binary protocol?
[...]
> The performance benefit will be minimal ([...]).
>
> COPY matters on INSERT for sure performance-wise.
> So why wouldn't COPY matter for SELECTs too?

COPY is faster than a bunch of INSERTs because each INSERT has some
overhead: It needs to be parsed (if you PREPAREd the INSERT you need to
parse the EXECUTE command instead) and planned. But most importantly you
have a round trip time between the client and the server. With COPY you
incur that overhead only once.

(Which reminds me that I should benchmark INSERT with lots of VALUES
against COPY some time.)

With COPYing the output of a SELECT I don't see any savings. On the
contrary, it's an extra step.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp(at)hjp(dot)at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Peter J. Holzer 2023-03-17 23:37:10 Re: EXTERNAL: Re: "No Free extents", table using all allocated space but no rows!
Previous Message jian he 2023-03-17 16:42:11 Re: src/test/examples/testlibpq2.c where the HAVE_SYS_SELECT_H is defined.