declare cursor with hold+fetch count vs PQsendQuery+PQsetSingleRowMode - resource consumption and the efficiency - Mailing list pgsql-general

From sftf
Subject declare cursor with hold+fetch count vs PQsendQuery+PQsetSingleRowMode - resource consumption and the efficiency
Date
Msg-id 1704537886.20150105223557@mail.ru
Whole thread Raw
List pgsql-general
Hello!
I would like to use "pagination" in my intranet client app.
My aims:
   - allow user to open and scroll large lists from query (without narrowing the query)
   - at the same time minimize time until the showing of large lists to the user
   - and at the same time minimize backend-frontend traffic as possible (not loading all at once)

User opens potentially large list of some documents and
visually scrolls through the list opening some another related lists (master-detail queries).
All those lists stays opened and should be scrollable until user closes them.
Number of opened lists per each session is about <= 20.

Basically there is two possibilities:
1. Client app explicitly open cursor and fetch records on demand.
Cursors should remain open until the user closes corresponding list of documents -
from minutes to hours.

2. Client app use PQsendQuery with PQsetSingleRowMode and PQgetResult insteed of PQExec.
This variant forces to use one connection to backend per each opened list (each PQsendQuery).
So insteed of one connection it would be dozens of.

And questions are:
1. How much and what resources (cpu/mem/processes) "eats" each cursor/connection on backend?
2. From what resource usage of cursor/connection depends?
3. What would be more efficient in terms of resource usage and maybe speed?



pgsql-general by date:

Previous
From: Edson Richter
Date:
Subject: Re: Replication: How to query current segments allocation relative to "Wal keep segments"?
Next
From: xu xiut
Date:
Subject: postgresql versus riak for a global exchange