RE: partition pruning only works for select but update

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

In response to

Responses

Browse pgsql-performance by date

  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