Re: BUG #16745: delete does not prune partitions on declarative partitioned table

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Christian <akattunga(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16745: delete does not prune partitions on declarative partitioned table
Date: 2020-11-26 04:49:05
Message-ID: CAApHDvqYiaeoXfV4OOSn0BG6+mGRBOYUTMmB5nAf9pB-zm6rSQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, 26 Nov 2020 at 11:34, Christian <akattunga(at)gmail(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Smith 2020-11-26 06:54:23 Re: BUG #16643: PG13 - Logical replication - initial startup never finishes and gets stuck in startup loop
Previous Message Amit Kapila 2020-11-26 02:45:29 Re: BUG #16643: PG13 - Logical replication - initial startup never finishes and gets stuck in startup loop