| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, 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 17:49:10 |
| Message-ID: | 19875.1417628950@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Atri Sharma <atri(dot)jiit(at)gmail(dot)com> writes:
> Is it possible to only replan part of the plan in case of this
> optimization? I think that we might need to only replan parts of the
> original plan (as you mentioned, join search and above). So we could reuse
> the original plan in part and not do a lot of replanning (an obvious case
> is scan strategy, which we can assume will not change for the two plans).
I think you assume wrong; or at least, I certainly would not wish to
hard-wire any such assumption. Skipping some joins could change the
shape of the join tree *completely*, because the cost estimates will
change so much. And that could in turn lead to making different choices
of scan methods, eg, we might or might not care about sort order of
a scan result if we change join methods.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Atri Sharma | 2014-12-03 17:54:32 | Re: Removing INNER JOINs |
| Previous Message | Joe Conway | 2014-12-03 17:42:17 | changing primary key col(s) with minimal impact |