Re: postgres_fdw bug in 9.6

On Thu, Jan 5, 2017 at 8:20 AM, Etsuro Fujita
<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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