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 86B04D7115 for ; Thu, 10 Nov 2005 15:27:25 -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 27905-07 for ; Thu, 10 Nov 2005 19:27:23 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from svr2.postgresql.org (svr2.postgresql.org [65.19.161.25]) by svr1.postgresql.org (Postfix) with ESMTP id AE9AFD70C0 for ; Thu, 10 Nov 2005 15:27:23 -0400 (AST) Received: from stark.xeocode.com (stark.xeocode.com [216.58.44.227]) by svr2.postgresql.org (Postfix) with ESMTP id 3D566F0B1E for ; Thu, 10 Nov 2005 19:27:24 +0000 (GMT) Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) by stark.xeocode.com with smtp (Exim 3.36 #1 (Debian)) id 1EaI4s-0002W9-00; Thu, 10 Nov 2005 14:27:18 -0500 To: Frank van Vugt Cc: pgsql-interfaces@postgresql.org, Tom Lane Subject: Re: Incremental results from libpq References: <4D426B54-E08F-4DE9-9776-D46610CA4968@slamb.org> <19391.1131571328@sss.pgh.pa.us> <84C7635D-EAF2-40CF-A71C-976077D5465A@slamb.org> <200511101751.55377.ftm.van.vugt@foxi.nl> In-Reply-To: <200511101751.55377.ftm.van.vugt@foxi.nl> From: Greg Stark Organization: The Emacs Conspiracy; member since 1992 Date: 10 Nov 2005 14:27:18 -0500 Message-ID: <877jbgb8x5.fsf@stark.xeocode.com> Lines: 16 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/18 X-Sequence-Number: 5814 Frank van Vugt writes: > I'm wondering, what kind of failure do you have in mind, here? If I'm informed > correctly then Oracle and others are generating the complete static result > set on the server-side, which will then stay cached until all rows/chunks are > fetched. That's obviously not true. Try doing "select * from huge_table" on Oracle and you'll see records start appearing immediately. There are applications where huge_table could occupy hundreds of gigabytes (or petabytes) and requiring all queries to create copies of all their result sets before proceeding would make lots of important applications entirely infeasible. -- greg