Re: create_unique_path and GEQO

Rushabh Lathia <rushabh.lathia@gmail.com>

From: Rushabh Lathia <rushabh.lathia@gmail.com>
To: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-03-24T06:22:11Z
Lists: pgsql-hackers
On Wed, Mar 22, 2017 at 3:43 PM, Ashutosh Bapat <
ashutosh.bapat@enterprisedb.com> wrote:

> Hi,
> In create_unique_path() there's comment
>     /*
>      * We must ensure path struct and subsidiary data are allocated in main
>      * planning context; otherwise GEQO memory management causes trouble.
>      */
>     oldcontext = MemoryContextSwitchTo(root->planner_cxt);
>
>     pathnode = makeNode(UniquePath);
>
> This means that when GEQO resets the memory context, the RelOptInfo
> for which this path is created and may be set to cheapest_unique_path
> goes away, the unique path lingers on in the planner context.
> Shouldn't we instead allocate the path in the same context as the
> RelOptInfo similar to mark_dummy_rel()?
>
>
Do you have test case, which can reproduce the issue you
explained above?


> --
> Best Wishes,
> Ashutosh Bapat
> EnterpriseDB Corporation
> The Postgres Database Company
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>



-- 
Rushabh Lathia

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.