X-Original-To: pgsql-patches-postgresql.org@postgresql.org
Received: from localhost (mx1.hub.org [200.46.208.251])
	by postgresql.org (Postfix) with ESMTP id BB4C29FB269
	for <pgsql-patches-postgresql.org@postgresql.org>;
	Wed,  2 Aug 2006 10:58:42 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024)
	with ESMTP id 55863-01 for
	<pgsql-patches-postgresql.org@postgresql.org>;
	Wed,  2 Aug 2006 10:58:33 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from joeconway.com (joeconway.com [68.15.9.201])
	by postgresql.org (Postfix) with ESMTP id 65A889FA004
	for <pgsql-patches@postgresql.org>;
	Wed,  2 Aug 2006 10:58:33 -0300 (ADT)
Received: from [192.168.4.40] (account jconway [192.168.4.40] verified)
	by joeconway.com (CommuniGate Pro SMTP 4.1.8)
	with ESMTP-TLS id 4138865; Wed, 02 Aug 2006 06:58:31 -0700
Message-ID: <44D0AF87.2030304@joeconway.com>
Date: Wed, 02 Aug 2006 06:58:31 -0700
From: Joe Conway <mail@joeconway.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-patches@postgreSQL.org
Subject: Re: Values list-of-targetlists patch for comments (was Re: 
References: <44B69778.5050104@dunslane.net>
	<50461.84.63.113.55.1152832991.squirrel@pezone.net>
	<ECCAAC0A3182895D3D12B0E8@[172.26.14.247]>
	<44B7ADFC.90205@dunslane.net> <44D03D9F.80203@joeconway.com>
	<15263.1154526181@sss.pgh.pa.us>
In-Reply-To: <15263.1154526181@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.017 tagged_above=0 required=5 tests=AWL,
	SPF_HELO_PASS, SPF_PASS
X-Spam-Level: 
X-Archive-Number: 200608/53
X-Sequence-Number: 20569

Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
> 
>>This patch retains the memory consumption savings but doesn't break any 
>>regression tests...
> 
> 
> I'm unconvinced that retail pfree's are the way to go.  I just did some
> profiling of this test case:

<snip>

> It's slightly depressing that there's not more time being spent in
> places we can easily tweak, but anyway the salient point to me is
> that AllocSetFree is already chewing a nontrivial part of the runtime.

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.

Joe