Re: Foreign join pushdown vs EvalPlanQual

On Thu, Dec 10, 2015 at 1:32 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Dec 9, 2015 at 3:22 AM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> Sorry, my explanation might be not enough, but I'm not saying to hide the
>> subplan. I think it would be better to show the subplan somewhere in the
>> EXPLAIN outout, but I'm not sure that it's a good idea to show that in the
>> current form. We have two plan trees; one for normal query execution and
>> another for EvalPlanQual testing. I think it'd be better to show the
>> EXPLAIN output the way that allows users to easily identify each of the plan
>> trees.
>
> It's hard to do that because we don't identify that internally
> anywhere. Like I said before, the possibility of a ForeignScan having
> an outer subplan is formally independent of the new EPQ stuff, and I'd
> prefer to maintain that separation and just address this with
> documentation.

Fujita-san, others, could this be addressed with documentation?

> Getting this bug fixed has been one of the more exhausting experiences
> of my involvement with PostgreSQL, and to be honest, I think I'd like
> to stop spending too much time on this now and work on getting the
> feature that this is intended to support working. Right now, the only
> people who can have an opinion on this topic are those who are
> following this thread in detail, and there really aren't that many of
> those.

I am numbering that to mainly 3 people, you included :)

> If we get the feature - join pushdown for postgres_fdw -
> working, then we might get some feedback from users about what they
> like about it or don't, and certainly if this is a frequent complaint
> then that bolsters the case for doing something about it, and possibly
> also helps us figure out what that thing should be. On the other
> hand, if we don't get the feature because we're busy debating
> interface details related to this patch, then none of these details
> matter anyway because nobody except developer is actually running the
> code in question.

As this debate continues, I think that moving this patch to the next
CF would make the most sense then.. So done this way.
--
Michael