X-Original-To: pgsql-hackers@postgreSQL.org Received: from spampd.localdomain (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 76AF047635B; Thu, 10 Apr 2003 16:30:16 -0400 (EDT) Received: from europa.janwieck.net (h00045a2e4e7c.ne.client2.attbi.com [24.131.181.55]) by postgresql.org (Postfix) with ESMTP id 01866476351; Thu, 10 Apr 2003 16:30:12 -0400 (EDT) Received: from Yahoo.com (linksys.janwieck.net [192.168.192.1]) (authenticated) by europa.janwieck.net (8.11.6/8.11.6) with ESMTP id h3AKT2a07593; Thu, 10 Apr 2003 16:29:02 -0400 Message-ID: <3E95D3FE.5DE02EA6@Yahoo.com> Date: Thu, 10 Apr 2003 16:28:46 -0400 From: Jan Wieck Organization: Home X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Tom Lane Cc: Hannu Krosing , Peter Galbavy , pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org Subject: Re: More thoughts about FE/BE protocol References: <10478.1049927451@sss.pgh.pa.us> <003f01c2ff40$9f1a0e70$7c28a8c0@cblan.mblox.com> <3625.1049983061@sss.pgh.pa.us> <1049993435.1886.24.camel@fuji.krosing.net> <5015.1049993977@sss.pgh.pa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Archive-Number: 200304/339 X-Sequence-Number: 37829 Tom Lane wrote: > > Hannu Krosing writes: > > Tom Lane kirjutas N, 10.04.2003 kell 16:57: > >> See my response to ljb --- I think that in practice people assemble each > >> message before sending anyway. > > > I just tested it by running "select *" on 68M records (6.5 GB data) > > table and you seem to be wrong - while psql shows nothing, its size > > starts rapidly growing (I ^C it at ~500M) , while backend stays at > > stable 32M, which indicates that postgres starts to push data out as > > fast as it can get it. > > Sure. "Message" here is at the granularity of one data row, not an > entire query result. Could even be smaller since TOASTed items don't get loaded at the row level but rather one after another. So a 68M row consisting of 4 17M fields doesn't require 68M of memory to be sent to the client. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #