Re: DELETE / UPDATE from partition not optimized (11.0)

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Dave E Martin <postgresql2-to(dot)dave(at)dave(dot)to>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: DELETE / UPDATE from partition not optimized (11.0)
Date: 2018-10-28 21:49:24
Message-ID: 20181028214924.GA26843@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Oct 26, 2018 at 10:45:40AM -0500, Justin Pryzby wrote:
> On Thu, Oct 25, 2018 at 10:43:10AM -0600, Dave E Martin wrote:
> > If SELECT is confident enough to limit itself to one partition, why isn't
> > DELETE (or UPDATE)?
>
> Because of this limitation:
>
> https://www.postgresql.org/docs/current/static/ddl-partitioning.html#DDL-PARTITION-PRUNING
> |Currently, pruning of partitions during the planning of an UPDATE or DELETE
> |command is implemented using the constraint exclusion method (however, it is
> |controlled by the enable_partition_pruning rather than constraint_exclusion) —
> |see the following section for details and caveats that apply.

I meant to add that one can use a redundant constraints in addition to the
partition bounds, both specifying the same condition. That also allows
detaching and re-attaching the partition without a table scan (which is why we
do it).

Justin

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Uday Bhaskar V 2018-10-29 13:29:40 Indexes on UUID - Fragmentation Issue
Previous Message Jeff Janes 2018-10-26 17:54:32 Re: Gained %20 performance after disabling bitmapscan