Re: [HACKERS] create_unique_path and GEQO - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] create_unique_path and GEQO
Date
Msg-id CAB7nPqT+uEKG61o3JNJEHFSMk+CtEbhnPCXh5FMUR49ceQQ37g@mail.gmail.com
Whole thread Raw
In response to Re: create_unique_path and GEQO  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] create_unique_path and GEQO  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
List pgsql-hackers
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.
-- 
Michael


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] pg_serial early wraparound
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr