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
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 |