Re: Removing INNER JOINs

From: Atri Sharma <atri(dot)jiit(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mart Kelder <mart(at)kelder31(dot)nl>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Removing INNER JOINs
Date: 2014-12-03 15:54:00
Message-ID: CAOeZVichLeyn=K4mwCJTwCrzGUaKXK+KSYz06rSAn0xpTCV2=A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 3, 2014 at 8:32 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> * Atri Sharma (atri(dot)jiit(at)gmail(dot)com) wrote:
> > So the planner keeps all possibility satisfying plans, or it looks at the
> > possible conditions (like presence of foreign key for this case, for eg)
> > and then lets executor choose between them?
>
> Right, this was one of the thoughts that I had.
>
> > So is the idea essentially making the planner return a set of "best"
> plans,
> > one for each condition? Are we assured of their optimality at the local
> > level i.e. at each possibility?
>
> We *already* have an idea of there being multiple plans (see
> plancache.c).
>
>
> Thanks for pointing me there.

What I am concerned about is that in this case, the option plans are
competing plans rather than separate plans.

My main concern is that we might be not able to discard plans that we know
that are not optimal early in planning. My understanding is that planner is
aggressive when discarding potential paths. Maintaining them ahead and
storing and returning them might have issues, but that is only my thought.

--
Regards,

Atri
*l'apprenant*

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-12-03 15:56:20 Re: Removing INNER JOINs
Previous Message Robert Haas 2014-12-03 15:51:19 Re: Removing INNER JOINs