Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)
От | Etsuro Fujita |
---|---|
Тема | Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs) |
Дата | |
Msg-id | 566A9BFD.7070001@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs) (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: