Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tUlBd-002Srp-OS for pgsql-general@arkaria.postgresql.org; Mon, 06 Jan 2025 11:22:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tUlBc-007zIl-8H for pgsql-general@arkaria.postgresql.org; Mon, 06 Jan 2025 11:22:19 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tUXuG-002qFV-5H for pgsql-general@lists.postgresql.org; Sun, 05 Jan 2025 21:11:31 +0000 Received: from mail-oi1-x22c.google.com ([2607:f8b0:4864:20::22c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tUXuC-0003Tu-1k for pgsql-general@lists.postgresql.org; Sun, 05 Jan 2025 21:11:31 +0000 Received: by mail-oi1-x22c.google.com with SMTP id 5614622812f47-3eb8accbde3so7210251b6e.0 for ; Sun, 05 Jan 2025 13:11:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736111487; x=1736716287; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=MdWm9yBbthyPcpjD6f3/WCju5w83vqJF41n2LJKx3hw=; b=kXrzcfFi89uXO/5HX9JqneUtEyQd2NvPaG2JD3ADpCxPDiCjCYt1uemE1RTZ6FlCCN edBXM6cj5kgvRz7uoBgQAwImaMv6Yz15cg+A1E8f8CWaG2/l+1OiAxaunMfRy5MjT4yt ReUPuW/A08lB+Rzj0SDypmgTQXKinyBbRSBDhimnhABtqftgRk0t8EnlK5ExgqtLHrid 1pl+AMQKiIzlxdLUiBZATCDBFjxZxuMm7/ZRCrCzneq8C5bzt68dAaQTfn7LYIcXHz6o CRFeF8Hc+YSSKv4i0nSbSi+YUwEF3M+8aHM8ssR9g18Hms0HmsHzZ+YRHJ04xGZRfHut 15kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736111487; x=1736716287; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=MdWm9yBbthyPcpjD6f3/WCju5w83vqJF41n2LJKx3hw=; b=omZ8l4xZbG+t3qMeJ3jIuqyfPk4h0MsHgZm+LUvX4M31GZjX9JxOKPgiKJmKamkQaW tanEQK0PPfSfXalvjmU9kz85vciqEW46uWaPi5SDy/v1eK16FJ3q8j0h1iktp5ZNHVZk SbWmdAflQrkP2XQbt25sNg5yXn0ON8uRFxRcqNduJoXnMurYsognaabkctOV75LMhq2o ad7d/RcigWSqIfiY2Ep1jhG4EXQNTCXvaTZH0y5xWgvUqDkpKywsWWIYHfTHjsCS7VQz v8vadsb7zhtOkiMkrj2G791oze9K5uBsuMfP88wmKNpkBI4e2GQ2tV9ALV1c4FtGrXXL oeRw== X-Gm-Message-State: AOJu0YwPQqbClM8qG6eyl/7it9Ccm/DpYExkKoXZridND3ykfnka6IdO iWTEQCF1+kb4DrfLJTJ/ob1rJ8f7+4+nrvjAGHf5um0Dqn0HBBFsz53hXSi5SOD/fNdq6R4pSML ayTxPhB7ks2mBZJ8OxsiIHPjrXfsGV4DC X-Gm-Gg: ASbGncsSIn/dyAJ0JsOYs45fA5FfQcGFXP05mBMYCbtP5wDdiUDyT5J4Ci14UxWehtU QoFSxboeIILQ0g0F5pYhGMI/tw9oNfvogdhK28enjYi+ngZBtPkPbbnNAnhDGoimKXHlRD6Mp X-Google-Smtp-Source: AGHT+IFYZS7K527XlevqOWW1FiTbu2zvMZweWVV3Jw1Ai7dXWkyJ1/HbfkfBBfrSah+YGQNxrP/n33je0KkY1g9iI4A= X-Received: by 2002:a05:6808:188c:b0:3e6:d7:9464 with SMTP id 5614622812f47-3ecdd72bb9amr30301448b6e.14.1736111486918; Sun, 05 Jan 2025 13:11:26 -0800 (PST) MIME-Version: 1.0 From: Stijn Sanders Date: Sun, 5 Jan 2025 22:11:16 +0100 Message-ID: Subject: Will PQsetSingleRowMode get me results faster? To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000077e672062afbf43d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000077e672062afbf43d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've been using LibPQ to get data from PostgreSQL instances with great success. I'm using PQsendQuery and PQgetResult, but noticed there's also PQsetSingleRowMode. The documentation is clearly stating it only benefits a limited set of scenario's, but I'm saddened that it can't help to get the first resulte of a (longer running) query faster. There's a different database solution I won't name here that has a thing they call 'firehose mode' that in fact does this: their equivalent of PQntuples actually returns -1 in this mode, and you're expected to use their equivalent of PQgetResult to get record per record ** as it is rolling in from the server while the query is still running **. From what I notice using LibPQ, it appears a query needs to complete before resulting data is being transferred to the client. Please correct me if I'm wrong. Please point me in the correct direction if I'm missing something and I need to look elsewhere. (I just now notice there's a PQsetChunkedRowsMode now =E2=80=94nice! =E2=80=94 but I suspect the above still holds.) Should I attempt to use LIMIT and OFFSET to limit the running time of queries to get results faster? This will still interrupt the query and add overhead of starting and stopping each query, even using PQexecPrepared, I guess... Greetings Stijn --00000000000077e672062afbf43d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've been using LibPQ to get data from Postgr= eSQL instances with great success.
I'm using=C2=A0PQsend= Query and=C2=A0PQgetResult, but noticed there's also=C2=A0PQsetSingleRo= wMode.
The documentation is clearly stating it only benefits = a limited set of scenario's, but I'm saddened that it can't hel= p to get the first resulte of a (longer running) query faster.

There's a different database solution I won't = name here that has a thing they call 'firehose mode' that in fact d= oes this: their equivalent of=C2=A0PQntuples actually returns -1 in this mo= de, and you're expected to use their equivalent of PQgetResult to get r= ecord per record ** as it is rolling in from the server while the query is = still running **.

From what I notice using= LibPQ, it appears a query needs to complete before resulting data is being= transferred to the client. Please correct me if I'm wrong.

Please point me in the correct direction if I'm m= issing something and I need to look elsewhere. (I just now notice there'= ;s a=C2=A0PQsetChunkedRowsMode now =E2=80=94nice! =E2=80=94 but I suspect t= he above still holds.)

Should I attempt to= use LIMIT and OFFSET to limit the running time of queries to get results f= aster? This will still interrupt the query and add overhead of starting and= stopping each query, even using=C2=A0PQexecPrepared, I guess...

Greetings
Stijn
--00000000000077e672062afbf43d--