X-Original-To: pgsql-interfaces-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 79DE1D71BE for ; Sun, 13 Nov 2005 12:13:58 -0400 (AST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 58879-10 for ; Sun, 13 Nov 2005 16:13:55 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from stark.xeocode.com (stark.xeocode.com [216.58.44.227]) by svr1.postgresql.org (Postfix) with ESMTP id 8FE53D719A for ; Sun, 13 Nov 2005 12:13:55 -0400 (AST) Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) by stark.xeocode.com with smtp (Exim 3.36 #1 (Debian)) id 1EbKUH-0006iU-00; Sun, 13 Nov 2005 11:13:49 -0500 To: Alvaro Herrera Cc: "Goulet, Dick" , Frank van Vugt , Greg Stark , pgsql-interfaces@postgresql.org Subject: Re: Incremental results from libpq References: <4001DEAF7DF9BD498B58B45051FBEA6502EF5389@25exch1.vicorpower.vicr.com> <20051113152401.GB31570@surnet.cl> In-Reply-To: <20051113152401.GB31570@surnet.cl> From: Greg Stark Organization: The Emacs Conspiracy; member since 1992 Date: 13 Nov 2005 11:13:48 -0500 Message-ID: <87r79kwmo3.fsf@stark.xeocode.com> Lines: 32 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.01 required=5 tests=[AWL=0.010] X-Spam-Score: 0.01 X-Spam-Level: X-Archive-Number: 200511/23 X-Sequence-Number: 5819 Alvaro Herrera writes: > Postgres supports cursors too. The Qt guys, and everyone else, could be > using it to get incremental results right now, no libpq mods necessary. Not really since the way Postgres supports cursors is at the SQL level. Users of Qt and every other driver could be using cursors if their drivers support them, but Qt can't really be reasonably expected to go into users' SQL and modify them to use cursors. Moreover cursors aren't really that great a substitute. With cursors you have to manually fetch individual records. You're just trading off the inefficiencies of batching up all the results for entirely different inefficiencies. Now for every record you retrieve you need a network round trip as well as a round trip down through your driver, the kernel layers on both machines, and the backend as well. The efficient approach as Oracle and other mature network layers implement is to issue the query once, then pipeline the results back to the application buffering a substantial amount in the driver. DBD::Oracle goes to some lengths to ensure the number of records buffered is a reasonable multiple of the default TCP mss of 1500 bytes. So even though the application only retrieves one record at a time it's just pulling it out of an array that's already prefilled. When the array gets low the next block of records is retrieved from the server (where they're probably already buffered as well). The result is a constant flow of network traffic that keeps the application and network as busy as possible. -- greg