l-performance@lists.postgresql.org
Subject: Re: partition pruning only works for select but update
Justin Pryzby writes:
> On Fri, Jul 01, 2022 at 08:30:40AM +, James Pang (chaolpan) wrote:
>> We have other application depend on V13, possible to backport code
>> changes to V13 as
>> ht
Justin Pryzby writes:
> On Fri, Jul 01, 2022 at 08:30:40AM +, James Pang (chaolpan) wrote:
>> 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
> I
> Sent: Tuesday, June 28, 2022 9:30 PM
> To: James Pang (chaolpan)
> Cc: pgsql-performance@lists.postgresql.org
> Subject: Re: partition pruning only works for select but update
>
> "James Pang (chaolpan)" writes:
> > But when
> > Explain update tab
Pang (chaolpan)
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: partition pruning only works for select but update
"James Pang (chaolpan)" writes:
> But when
> Explain update table set .. where partitionkey between to_timestamp() and
> to_timestamp();
>
Pang (chaolpan)
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: partition pruning only works for select but update
"James Pang (chaolpan)" writes:
> But when
> Explain update table set .. where partitionkey between to_timestamp() and
> to_timestamp();
> It still
"James Pang (chaolpan)" 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.
Hi,
We have a table have range partition (about 5K partitions) , when
Explain select count(*) from table where partitionkey between to_timestamp()
and to_timestamp();
It show
Aggregate (cost=15594.72..15594.73 rows=1 width=8)
-> Append (cost=0.15..15582.00 rows=5088 width=0)
Sub
