Re: BUG #16745: delete does not prune partitions on declarative partitioned table - Mailing list pgsql-bugs

From David Rowley
Subject Re: BUG #16745: delete does not prune partitions on declarative partitioned table
Date
Msg-id CAApHDvqYiaeoXfV4OOSn0BG6+mGRBOYUTMmB5nAf9pB-zm6rSQ@mail.gmail.com
Whole thread Raw
In response to Re: BUG #16745: delete does not prune partitions on declarative partitioned table  (Christian <akattunga@gmail.com>)
List pgsql-bugs
On Thu, 26 Nov 2020 at 11:34, Christian <akattunga@gmail.com> wrote:
> Ok so this is a known issue.

The reason you don't get the behaviour that you'd like is that there
is no run-time partition pruning for UPDATE/DELETE.  The current_date
cannot be evaluated during query planning, so plan-time partition
pruning cannot be done then.

If you know for certain that you or your client never prepare queries,
meaning, planning always takes place just before execution, then you
might be able to get away with:

delete FROM FAC_ITEM WHERE FCODDIST='' AND FSUCURS=1 AND FFECHAI =
'today'::date;

The 'today'::date will be evaluated earlier enough that the planner
will be able to perform partition pruning using the current date.

Just be aware, if you do cache plans somewhere the date will be cached
along with them. Things will start going badly for you after midnight.

David



pgsql-bugs by date:

Previous
From: Amit Kapila
Date:
Subject: Re: BUG #16643: PG13 - Logical replication - initial startup never finishes and gets stuck in startup loop
Next
From: Peter Smith
Date:
Subject: Re: BUG #16643: PG13 - Logical replication - initial startup never finishes and gets stuck in startup loop