On Thu, Nov 30, 2017 at 9:00 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > On Thu, Nov 30, 2017 at 8:50 AM, Michael Paquier > <michael.paqu...@gmail.com> wrote: >> On Fri, Mar 24, 2017 at 10:50 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> writes: >>>>> Do you have test case, which can reproduce the issue you >>>>> explained above? >>> >>>> No. It would require some surgery in standard_planner() to measure the >>>> memory consumed in the planner context OR build the code with >>>> SHOW_MEMORY_STATS defined and dump memory context statistics and check >>>> planner context memory usage. I don't think I can produce a testcase >>>> quickly right now. But then, I think the problem is quite apparent >>>> from the code inspection alone, esp. comparing what mark_dummy_rel() >>>> does with what create_unique_path() is doing. >>> >>> Yeah. I think the code in mark_dummy_rel is newer and better-thought-out >>> than what's in create_unique_path. It probably makes sense to change over. >> >> This has remained unanswered for more than 8 months, so I am marking >> this patch as returned with feedback. > > I am not sure what's there to answer in Tom's reply. He seems to be > agreeing with my analysis. Correct me if I am wrong. If that's the > case, I am expecting somebody to review the patch. If there are no > review comments, some committer may commit it. >
For now I have marked it as need reviewer and moved to the next commitfest. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
