On Thu, Nov 30, 2017 at 8:50 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Fri, Mar 24, 2017 at 10:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Ashutosh Bapat <ashutosh.bapat@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
