From: Tom Lane <tgl@sss.pgh.pa.us>
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
Date: Sat, 04 Dec 2010 11:42:03 -0500
Message-ID: <23792.1291480923@sss.pgh.pa.us> (raw)
In-Reply-To: <idd14l$a4u$1@news.hub.org>
References: <idbo6g$92r$1@news.hub.org>
<14012.1291443654@sss.pgh.pa.us>
<idd14l$a4u$1@news.hub.org>
John Papandriopoulos <dr.jpap@gmail.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, dr.jpap@gmail.com
Subject: Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
In-Reply-To: <23792.1291480923@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox