On 2015/12/02 1:54, Robert Haas wrote:
On Fri, Nov 27, 2015 at 1:25 AM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote:
Sorry, I don't understand this. In my understanding, fdw_recheck_quals
can be defined for a foreign join, regardless of the join type,
Yes, "can be defined", but will not be workable if either side of
joined tuple is NULL because of outer join. SQL functions returns
NULL prior to evaluation, then ExecQual() treats this result as FALSE.
However, a joined tuple that has NULL fields may be a valid tuple.
We don't need to care about unmatched tuple if INNER JOIN.
This is a really good point, and a very strong argument for the design
KaiGai has chosen here.
Maybe my explanation was not enough. Sorry about that. But I mean that
we define fdw_recheck_quals for a foreign-join as quals that 1) were
extracted by extract_actual_join_clauses as "otherclauses"
(rinfo->is_pushed_down=true) and that 2) were pushed down to the remote
server, not scan quals relevant to all the base tables invoved in the
foreign-join. So in this definition, I think fdw_recheck_quals for a
foreign-join will be workable, regardless of the join type.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
