On 2015/12/11 14:16, Ashutosh Bapat wrote:
> On Thu, Dec 10, 2015 at 11:20 PM, Robert Haas <robertmhaas@gmail.com
> <mailto:robertmhaas@gmail.com>> wrote:
> On Tue, Dec 8, 2015 at 6:40 AM, Etsuro Fujita
> <fujita.etsuro@lab.ntt.co.jp <mailto:fujita.etsuro@lab.ntt.co.jp>>
> wrote:
> > IMO I want to see the EvalPlanQual fix in the first version for 9.6.
>
> +1.
> I think there is still a lot functionality that is offered without
> EvalPlanQual fix. As long as we do not push joins when there are
> RowMarks involved, implementation of that hook is not required. We won't
> be able to push down joins for DMLs and when there are FOR SHARE/UPDATE
> clauses in the query. And there are huge number of queries, which will
> be benefitted by the push down even without that support. There's
> nothing in this patch, which comes in way of implementing the
> EvalPlanQual fix. It can be easily added after committing the first
> version. On the other hand, getting minimal (it's not really minimal,
> it's much more than that) support for postgres_fdw support committed
> opens up possibility to work on multiple items (as listed in my mail) in
> parallel.
> I am not saying that we do not need EvalPlanQual fix in 9.6. But it's
> not needed in the first cut. If we get the first cut in first couple of
> months of 2016, there's plenty of room for the fix to go in 9.6. It
> would be really bad situation if we could not get postgres_fdw join
> pushdown supported in 9.6 because EvalPlanQual hook could not be
> committed while the rest of the code is ready. EvalPlanQual fix in core
> was being discussed since April 2015. It took 8 months to get that
> fixed. Hopefully we won't need that long to implement the hook in
> postgres_fdw, but that number says something about the complexity of the
> feature.
ISTM that further enhancements are of secondary importance. Let's do the
EvalPlanQual fix first. I'll add the RecheckForeignScan callback routine
to your version of the postgres_fdw patch as soon as possible.
Best regards,
Etsuro Fujita