X-Original-To: pgsql-patches-postgresql.org@postgresql.org Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 14AB19FB1D7 for ; Wed, 2 Aug 2006 11:25:28 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 20933-10 for ; Wed, 2 Aug 2006 14:25:11 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id C4B2E9FB256 for ; Wed, 2 Aug 2006 11:25:10 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k72EP8tZ016893; Wed, 2 Aug 2006 10:25:08 -0400 (EDT) To: Joe Conway cc: pgsql-patches@postgreSQL.org Subject: Re: Values list-of-targetlists patch for comments (was Re: In-reply-to: <44D0AF87.2030304@joeconway.com> References: <44B69778.5050104@dunslane.net> <50461.84.63.113.55.1152832991.squirrel@pezone.net> <44B7ADFC.90205@dunslane.net> <44D03D9F.80203@joeconway.com> <15263.1154526181@sss.pgh.pa.us> <44D0AF87.2030304@joeconway.com> Comments: In-reply-to Joe Conway message dated "Wed, 02 Aug 2006 06:58:31 -0700" Date: Wed, 02 Aug 2006 10:25:08 -0400 Message-ID: <16892.1154528708@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=3.816 tagged_above=0 required=5 tests=SPF_HELO_SOFTFAIL, SPF_SOFTFAIL X-Spam-Level: *** X-Archive-Number: 200608/55 X-Sequence-Number: 20571 Joe Conway writes: > That's undoubtedly true, and important for the case that isn't memory > constrained (but where I'm already seeing us perform relatively well). > But once we start the machine swapping, runtime goes in the toilet. And > without addressing the memory leak somehow, we will start a machine > swapping significantly earlier than mysql. I'm not arguing that we don't need to work on the memory usage ... just that I'm not very happy with that particular approach. I wonder whether there is any reasonable way to determine which data structures are responsible for how much space ... in my test I'm seeing MessageContext: 822075440 total in 104 blocks; 4510280 free (1 chunks); 817565160 used ExecutorState: 8024624 total in 3 blocks; 20592 free (12 chunks); 8004032 used so it seems mostly not the executor's fault, but that's not much to go on. regards, tom lane