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