On Fri, 30 Nov 2018 at 20:15, Kato, Sho wrote:
> Will we improve creating the generic plan in the future?
I think Amit's patch will improve the UPDATE/DELETE planning
performance even when nothing can be pruned. Currently planning those
are quite inefficient as a separate grouping planner call i
[mailto:langote_amit...@lab.ntt.co.jp]
> Sent: Friday, November 30, 2018 3:44 PM
> To: David Rowley
> Cc: Kato, Sho/加藤 翔 ; PostgreSQL Hackers
>
> Subject: Re: Planning time of Generic plan for a table partitioned into
> a lot
>
> On 2018/11/30 14:58, David Rowley wrote:
> > On
On Fri, 30 Nov 2018 at 19:44, Amit Langote
wrote:
> Yeah, maybe we haven't explained in the documentation where generic plans
> are described that making them for partitioned table is an expensive
> affair. Although, by definition, they are built once for a given query
> and PG 11 with it's execu
On 2018/11/30 14:58, David Rowley wrote:
> On Fri, 30 Nov 2018 at 15:04, Amit Langote
> wrote:
>>
>> On 2018/11/29 19:54, David Rowley wrote:
>>> The problem is only made worse in PG11 from PG10
>>> because generating the custom plan has become faster than it
>>> previously was due to the new part
On Fri, 30 Nov 2018 at 15:04, Amit Langote
wrote:
>
> On 2018/11/29 19:54, David Rowley wrote:
> > The problem is only made worse in PG11 from PG10
> > because generating the custom plan has become faster than it
> > previously was due to the new partition pruning code which might make
> > it appe
s of partitions.
Ok, I got it.
Regards,
Sho Kato
> -Original Message-
> From: David Rowley [mailto:david.row...@2ndquadrant.com]
> Sent: Thursday, November 29, 2018 7:55 PM
> To: Kato, Sho/加藤 翔
> Cc: Amit Langote ; PostgreSQL Hackers
>
> Subject: Re: Planning time o
On 2018/11/29 19:54, David Rowley wrote:
> The problem is only made worse in PG11 from PG10
> because generating the custom plan has become faster than it
> previously was due to the new partition pruning code which might make
> it appear we can handle more partitions than we could previously,
Actu
On Thu, 29 Nov 2018 at 20:40, Kato, Sho wrote:
> Sorry for my lack of explanation. I didn't get a generic plan with
> plan_cache_mode = auto.
> What I am worried about is that if users don't know the flow of PREPARE
> EXECUTE, query execution seems to be suddenly slow and they will be in
> trou
rom: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp]
> Sent: Wednesday, November 28, 2018 2:52 PM
> To: Kato, Sho/加藤 翔 ;
> pgsql-hackers@lists.postgresql.org
> Cc: David Rowley
> Subject: Re: Planning time of Generic plan for a table partitioned into
> a lot
>
> On 2018/11/
all partitions with force_generic_plan, which
takes time to plan.
Regards,
Sho Kato
> -Original Message-
> From: David Rowley [mailto:david.row...@2ndquadrant.com]
> Sent: Wednesday, November 28, 2018 1:23 PM
> To: Kato, Sho/加藤 翔
> Cc: PostgreSQL Hackers
> Subject: Re:
On 2018/11/28 13:46, Amit Langote wrote:
> It's cheaper than using a cached generic plan (without re-planning),
> because the latter has to pay the cost of AcquireExecutorLocks which takes
> longer as the number of partitions increases. Perhaps something to try
> fix fixing too. Not planning shou
Hi Kato-san,
On 2018/11/27 19:05, Kato, Sho wrote:
> Of course, in case of plan_cache_mode = force_custom_plan, it is not problem
> because unnecessary paths are pruned by speeding up planning with partitions
> patch[1].
>
> However, if plan_cachemode is force_generic_plan, generic plan is made
On Tue, 27 Nov 2018 at 23:05, Kato, Sho wrote:
> I found that making a generic plan of SELECT/UPDATE/DELETE for a table
> partitioned into thousands is slow.
> Especially, UPDATE/DELETE statement is too slow.
It's quite well known and also documented [1] that this is slow. The
manual reads:
"Cu
Hi,
I found that making a generic plan of SELECT/UPDATE/DELETE for a table
partitioned into thousands is slow.
Especially, UPDATE/DELETE statement is too slow.
I'm afraid that I could not come up with a good idea, but how can I shorten the
creation time of a generic plan?
The results are as fol
14 matches
Mail list logo
