Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: John Papandriopoulos <dr(dot)jpap(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
Date: 2010-12-05 20:14:38
Message-ID: 29662.1291580078@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Rob Wultsch 2010-12-05 20:40:28 Group commit and commit delay/siblings
Previous Message Tom Lane 2010-12-05 16:56:03 Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT