Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i72yR-0004Gv-Fl for pgsql-sql@arkaria.postgresql.org; Sun, 08 Sep 2019 19:35:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1i72yQ-0004xs-9z for pgsql-sql@arkaria.postgresql.org; Sun, 08 Sep 2019 19:35:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i72yP-0004xl-VT for pgsql-sql@lists.postgresql.org; Sun, 08 Sep 2019 19:35:46 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1i72yN-0000yK-Jk for pgsql-sql@lists.postgresql.org; Sun, 08 Sep 2019 19:35:44 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x88JZc1Z024796; Sun, 8 Sep 2019 15:35:38 -0400 From: Tom Lane To: Christian Barthel cc: Sebastien FLAESCH , pgsql-sql@lists.postgresql.org Subject: Re: libpq: How are result sets fetched behind the scene? In-reply-to: <87zhjg8eep.fsf@x230.onfire.org> References: <6f2f210b-53e6-f350-4850-83f49b2a1354@4js.com> <7e0c3606-1513-1120-555a-6a14b615d939@4js.com> <87zhjg8eep.fsf@x230.onfire.org> Comments: In-reply-to Christian Barthel message dated "Sat, 07 Sep 2019 14:43:58 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <24794.1567971338.1@sss.pgh.pa.us> Date: Sun, 08 Sep 2019 15:35:38 -0400 Message-ID: <24795.1567971338@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Christian Barthel writes: > Sebastien FLAESCH writes: >> Is the whole result set fetched to the client app, not matter what row >> number is provided to the first PQgetvalue() call (or similar API call >> on result set data or meta-data)? > I have tested this as well and came to the same result as you. > The entire result set seems to be fetched at once. This must be so, and is documented as being so, because the abstraction that libpq provides is that a query either succeeds or fails. It cannot fetch a few rows and then decide that the query has succeeded; it has to collect the whole input before it knows there will be no late failure. Recent releases of libpq have an API to let you examine the rows as they come in, but then it's on your head to deal with the situation where an error occurs after you've already processed some rows. See https://www.postgresql.org/docs/current/libpq-single-row-mode.html You can alternatively use a cursor and FETCH a few rows at a time, as you mentioned. An error later than the first FETCH is still possible that way, but it's quantized in some sense --- any one FETCH either succeeds or fails. regards, tom lane