gt;
> Cc: Pg Hackers
> Subject: RE: Speeding up creating UPDATE/DELETE generic plan for
> partitioned table into a lot
>
> Before addressing to speeding up creating generic plan of UPDATE/DELETE,
> I will begin with the speed up creating SELECT plan.
>
> I will explain the
Before addressing to speeding up creating generic plan of UPDATE/DELETE, I will
begin with the speed up creating SELECT plan.
I will explain the background as time has passed.
Since generic plan creates plans of all partitions and is cached, we can skip
planning and expect performance improvemen
On Fri, 28 Dec 2018 at 20:36, Tsunakawa, Takayuki
wrote:
> Although I may say the same thing as you, I think a natural idea would be to
> create a generic plan gradually. The starting simple question is "why do we
> have to touch all partitions at first?" That is, can we behave like this:
>
>
From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp]
> Maybe, we can invent new types of plans for queries on partitioned tables
> that can be constructed by only looking at the parent relation. We'd need
> new infrastructure before we can begin working on that though. For
> example, until w
Kato-san,
On 2018/12/27 16:53, Kato, Sho wrote:
>> What do you mean by "since the partitions to access are partial"?
>
> I mean planner create scan nodes based on the parameters specified for
> EXECUTE and backend keep them in CachedPlan.
>
> Before:
>
> postgres=# explain execute update_stmt(
mber 21, 2018 5:45 PM
> To: Kato, Sho/加藤 翔 ;
> pgsql-hackers@lists.postgresql.org
> Subject: Re: Speeding up creating UPDATE/DELETE generic plan for
> partitioned table into a lot
>
> Kato-san,
>
> On 2018/12/21 15:36, Kato, Sho wrote:
> > Hi,
> > I want to speed up t
Kato-san,
On 2018/12/21 15:36, Kato, Sho wrote:
> Hi,
> I want to speed up the creation of UPDATE/DELETE generic plan for tables
> partitioned into a lot.
>
> Currently, creating a generic plan of UPDATE/DELTE for such table, planner
> creates a plan to scan all partitions.
> So it takes a very
