From: | "James Pang (chaolpan)" <chaolpan(at)cisco(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org> |
Subject: | RE: partition pruning only works for select but update |
Date: | 2022-07-01 08:30:40 |
Message-ID: | PH0PR11MB5191A8D08D5B27D084BC6BFBD6BD9@PH0PR11MB5191.namprd11.prod.outlook.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
We have other application depend on V13, possible to backport code changes to V13 as https://git.postgresql.org/gitweb/?p=postgresql.git;a=patch;h=86dc90056dfdbd9d1b891718d2e5614e3e432f35
Thanks,
James
-----Original Message-----
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Sent: Tuesday, June 28, 2022 9:30 PM
To: James Pang (chaolpan) <chaolpan(at)cisco(dot)com>
Cc: pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: partition pruning only works for select but update
"James Pang (chaolpan)" <chaolpan(at)cisco(dot)com> writes:
> But when
> Explain update table set .. where partitionkey between to_timestamp() and to_timestamp();
> It still show all of partitions with update ...
In releases before v14, partition pruning is far stupider for UPDATE (and DELETE) than it is for SELECT.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2022-07-01 13:13:11 | Re: partition pruning only works for select but update |
Previous Message | Justin Pryzby | 2022-06-29 19:52:33 | Re: Fluctuating performance of updates on small table with trigger |