Skip site navigation (1) Skip section navigation (2)

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-04 16:42:03
Message-ID: 23792.1291480923@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
John Papandriopoulos <dr(dot)jpap(at)gmail(dot)com> writes:
> I've recreated the same example with just one parent table, and 4096 child tables.

> SELECT query planning is lightning fast as before; DELETE and UPDATE cause my machine to swap.

> What's different about DELETE and UPDATE here?

Hmm.  Rules?  Triggers?  You seem to be assuming the problem is at the
planner stage but I'm not sure you've proven that.

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2010-12-04 16:59:58
Subject: Re: problem with from_collapse_limit and joined views
Previous:From: Віталій ТимчишинDate: 2010-12-04 15:32:16
Subject: Re: Slow query to get last created row using CURRVAL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group