RE: Planning time of Generic plan for a table partitioned into a lot

From: "Kato, Sho" <kato-sho(at)jp(dot)fujitsu(dot)com>
To: 'Amit Langote' <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>
Subject: RE: Planning time of Generic plan for a table partitioned into a lot
Date: 2018-11-29 07:40:29
Message-ID: 25C1C6B2E7BE044889E4FE8643A58BA963D8CE12@G01JPEXMBKW03
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, Amit

Thanks for your reply.
Your explanation is very easy to understand :)

On Wednesday, November 28, 2018 2:52 PM, Amit Langote wrote:
>Keeping aside the fact that making a generic plan gets increasing more expensive as the number of partitions increases, I'm a bit surprised that you get a generic plan with plan_cache_mode = auto. Isn't a generic plan way too expensive in this case?

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 trouble.
Just as you said, generic plan is only made, and a custom plan is chosen.
But, as the time to make a general plan is added, it becomes slow as a whole.

>Ah, I see that David has already thought about this issue.
>
>(last paragraph of this email)
>https://www.postgresql.org/message-id/CAKJS1f-ibmyn1W_UsdSmygjKOL6YgPyX0Mz54V_iD0HWWL_h%3Dg%40mail.gmail.com

Oh great! I am also concerned about AcquireExecutorLocks.
Ok, I'll take a look.

regards,
Sho Kato
> -----Original Message-----
> From: Amit Langote [mailto:Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp]
> Sent: Wednesday, November 28, 2018 2:52 PM
> To: Kato, Sho/加藤 翔 <kato-sho(at)jp(dot)fujitsu(dot)com>;
> pgsql-hackers(at)lists(dot)postgresql(dot)org
> Cc: David Rowley <dgrowleyml(at)gmail(dot)com>
> Subject: Re: Planning time of Generic plan for a table partitioned into
> a lot
>
> 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 should cost less than planning!
> > :)
>
> Ah, I see that David has already thought about this issue.
>
> (last paragraph of this email)
> https://www.postgresql.org/message-id/CAKJS1f-ibmyn1W_UsdSmygjKOL6Yg
> PyX0Mz54V_iD0HWWL_h%3Dg%40mail.gmail.com
>
> Thanks,
> Amit
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message myungkyu.lim 2018-11-29 08:43:26 RE: [Todo item] Add entry creation timestamp column to pg_stat_replication
Previous Message Amit Langote 2018-11-29 07:35:06 Re: Add pg_partition_tree to doc index