On Fri, Oct 16, 2015 at 5:00 AM, Etsuro Fujita
<fujita.etsuro@lab.ntt.co.jp> wrote:
> As for #2, I updated the patch, which uses a local join execution plan for
> an EvalPlanQual rechech, according to the comment from Robert [1]. Attached
> is an updated version of the patch. This is a WIP patch, but it would be
> appreciated if I could get feedback earlier.
I don't see how this can be right. You're basically just pretending
EPQ doesn't exist in the remote join case, which isn't going to work
at all. Those bits of code that look at es_epqTuple, es_epqTupleSet,
and es_epqScanDone are not optional. You can't just skip over those
as if they don't matter.
Again, the root of the problem here is that the EPQ machinery provides
1 slot per RTI, and it uses scanrelid to figure out which EPQ slot is
applicable for a given scan node. Here, we have scanrelid == 0, so it
gets confused. But it's not the case that a pushed-down join has NO
scanrelid. It actually has, in effect, *multiple* scanrelids. So we
should pick any one of those, say the lowest-numbered one, and use
that to decide which EPQ slot to use. The attached patch shows
roughly what I have in mind, although this is just crap code to
demonstrate the basic idea and doesn't pretend to adjust everything
that needs fixing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company