On Thu, Jan 5, 2017 at 8:20 AM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote: > On 2016/12/27 16:41, Etsuro Fujita wrote: >> >> On 2016/12/22 1:04, Ashutosh Bapat wrote: >>> >>> 2. We should try to look for other not-so-cheap paths if the cheapest >>> one is >>> paramterized. You might want to use get_cheapest_path_for_pathkeys() >>> to find a >>> suitable unparameterized path by passing NULL for required_outer and >>> NIL for >>> pathkeys, that's a very strange usage, but I think it will serve the >>> purpose. > > >>> + /* Give up if the cheapest-total-cost paths are parameterized. */ >>> + if (!bms_is_empty(PATH_REQ_OUTER(outer_path)) || >>> + !bms_is_empty(PATH_REQ_OUTER(inner_path))) >>> + return NULL; > > >> I did that because I think that would work well for postgres_fdw, but I >> agree with you. Will revise. > > > While working on this, I noticed that in that case > get_cheapest_path_for_pathkeys() would return NULL because if the > cheapest-total-cost path is parameterized, then there are no unparameterized > paths in the rel's pathlist (see set_cheapest).
I guess, that happens when there are lateral references, and every path for that relation in parameterized. Please correct me if I am wrong. If that's true, we should be searching for minimum parameterization for that relation instead of no parameterization. IIUC the bit about outer relations in the following comment in add_path() * We also remove from the rel's pathlist any old paths that are dominated * by new_path --- that is, new_path is cheaper, at least as well ordered, * generates no more rows, requires no outer rels not required by the old * path, and is no less parallel-safe. we do not discard an unparameterized path in favour of a cheaper parameterized path. So, if the cheapest path is unparameterized one, it's parameterized by minimum required outer relations. -- 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
