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

From: Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: John Papandriopoulos <dr(dot)jpap(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <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 21:58:10
Message-ID: 4CFAB972.5050806@vmsinfo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Tom Lane wrote:
> 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
>
>
Hmmm, I vaguely recollect a similar thread, started by me, although with
fewer partitions. In my experience, planner doesn't do a very good job
with partitions, especially with things like "min" or "max" which should
not be resolved by a full table scan, if there are indexes on partitions.

--
Mladen Gogala
Sr. Oracle DBA
1500 Broadway
New York, NY 10036
(212) 329-5251
www.vmsinfo.com

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2010-12-04 22:40:00 Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT
Previous Message John Papandriopoulos 2010-12-04 21:34:28 Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT