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-06-28 13:34:18 |
Message-ID: | PH0PR11MB519143DAE98DDDAC0E1AB717D6B89@PH0PR11MB5191.namprd11.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
For release v14, optimizer can handle large partition counts query ( select ,update ,delete) and partition pruning is similar as SELECT, right? We will check option to upgrade to v14.
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 | Mikkel Lauritsen | 2022-06-29 19:31:58 | Fluctuating performance of updates on small table with trigger |
Previous Message | Tom Lane | 2022-06-28 13:30:00 | Re: partition pruning only works for select but update |