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...@lab.ntt.co.jp] > Sent: Wednesday, November 28, 2018 2:52 PM > To: Kato, Sho/加藤 翔 <kato-...@jp.fujitsu.com>; > pgsql-hackers@lists.postgresql.org > Cc: David Rowley <dgrowle...@gmail.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 >
