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
ilto:kato-...@jp.fujitsu.com]
> Sent: Friday, February 1, 2019 5:16 PM
> To: Tsunakawa, Takayuki/綱川 貴之 ;
> 'David Rowley' ; Amit Langote
>
> Cc: Pg Hackers
> Subject: Speeding up creating UPDATE/DELETE generic plan for partitioned
> table into a lot
>
> Sor
Sorry, I lost previous mail[1].
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
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
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 long time.
I tried with a table partitioned into 8192, it took
