On Thu, Nov 30, 2017 at 9:00 AM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
> 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.
>
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
