Re: Removing INNER JOINs

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

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

> * Atri Sharma (atri(dot)jiit(at)gmail(dot)com) wrote:
> > Agreed, but in some cases, we could possibly make some assumptions (if
> > there is no index, if a large fraction of table will be returned in scan,
> > FunctionScan).
>
> All neat ideas but how about we get something which works in the way
> being asked for before we start trying to optimize it..? Maybe I'm
> missing something, but getting all of this infrastructure into place and
> making sure things aren't done to the plan tree which shouldn't be (or
> done to all of them if necessary..) is enough that we should get that
> bit done first and then worry if there are ways we can further improve
> things..
>
>
>
Right,sorry for digressing.

I think we are in agreement as to what needs to be done (start with a plan,
note ideas and replan if necessary). The idea of executor modifying the
plan (or personally, even choosing the plan) seems counterintuitive.

Does it also make sense to recalculate the costs from scratch for the
replan? It might be, I am just asking.

Regards,

Atri

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-12-03 18:08:08 Re: Removing INNER JOINs
Previous Message Stephen Frost 2014-12-03 17:57:31 Re: Removing INNER JOINs