Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id 25CD41337B61
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Sun,  5 Dec 2010 16:14:47 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024) with ESMTP id 19216-10
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Sun,  5 Dec 2010 20:14:39 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id 9E84B1337B50
	for <pgsql-performance@postgresql.org>;
	Sun,  5 Dec 2010 16:14:39 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id oB5KEc6j029663;
	Sun, 5 Dec 2010 15:14:38 -0500 (EST)
To: John Papandriopoulos <dr.jpap@gmail.com>
cc: pgsql-performance@postgresql.org
Subject: Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem
	compared to SELECT
In-reply-to: <26275.1291568163@sss.pgh.pa.us> 
References: <idbo6g$92r$1@news.hub.org> <14012.1291443654@sss.pgh.pa.us>
	<idd14l$a4u$1@news.hub.org> <23792.1291480923@sss.pgh.pa.us>
	<idec54$2hpd$1@news.hub.org> <13159.1291502400@sss.pgh.pa.us>
	<idfrnv$2bc$1@news.hub.org> <26275.1291568163@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sun, 05 Dec 2010 11:56:03 -0500"
Date: Sun, 05 Dec 2010 15:14:38 -0500
Message-ID: <29662.1291580078@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9,
	T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: 
X-Archive-Number: 201012/52
X-Sequence-Number: 41504

I wrote:
> You could get rid of the memory growth, at the cost of a lot of
> tree-copying, by doing each child plan step in a discardable memory
> context.  I'm not sure that'd be a win for normal sizes of inheritance
> trees though --- you'd need to copy the querytree in and then copy the
> resulting plantree out again, for each child.  (Hm, but we're doing the
> front-end copy already ...)

That worked better than I thought it would --- see
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=d1001a78ce612a16ea622b558f5fc2b68c45ab4c
I'm not intending to back-patch this, but it ought to apply cleanly to
9.0.x if you want it badly enough to carry a local patch.

			regards, tom lane