Horton

Re: create_unique_path and GEQO

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Cc: Rushabh Lathia <rushabh.lathia@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-03-24T13:50:18Z
Lists: pgsql-hackers 
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.

			regards, tom lane

Commits

  1. Make create_unique_path manage memory like mark_dummy_rel.

  2. Use parameterized paths to generate inner indexscans more flexibly.

  3. Ensure mark_dummy_rel doesn't create dangling pointers in RelOptInfos.

  4. Refactor planner's pathkeys data structure to create a separate, explicit

  5. IN clauses appearing at top level of WHERE can now be handled as joins.