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. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
