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

From: Dominique Devienne <ddevienne(at)gmail(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: Bryn Llewellyn <bryn(at)yugabyte(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general list <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-16 08:17:59
Message-ID: CAFCRh-8YnsZCEtzqfyr33mZd9gbR7vg45hFu8aqH5Eha3Cj6Gw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Mar 16, 2023 at 6:48 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
wrote:

> As we wrote, some of us think that cursors are useful, and we tried to
> explain why we think that. If you don't think that cursors are useful,
> don't use them. We are not out to convince you otherwise.
>

Perhaps OT (I only skimed this thread) but when I compared Cursors to
regular Statements / Queries
from a LIBPQ client application perspective, on the same "streamable"
queries (i.e. w/o a sort), Cursor
shined in terms of time-to-first-row, compared to waiting for the whole
ResultSet, but getting the full result
OTOH was 2x as long with Cursor, compared to the regular SELECT Statement.

Thus in my mind, it really depends on what you value in a particular
situation, latency or throughput. --DD

PS: In my testing, I used forward-only cursors
PPS: I don't recall the ResultSet cardinality or byte size, nor the
batching used with the Cursor.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Pavel Stehule 2023-03-16 08:23:12 Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?
Previous Message Jon Erdman 2023-03-16 06:38:46 Re: valgrind a background worker