Re: Foreign join pushdown vs EvalPlanQual

Поиск
Список
Период
Сортировка
От Etsuro Fujita
Тема Re: Foreign join pushdown vs EvalPlanQual
Дата
Msg-id 565EB870.1060700@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Foreign join pushdown vs EvalPlanQual  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2015/12/02 1:54, Robert Haas wrote:
> On Fri, Nov 27, 2015 at 1:25 AM, Kouhei Kaigai <kaigai@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





В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Shulgin, Oleksandr"
Дата:
Сообщение: Re: More stable query plans via more predictable column statistics
Следующее
От: Petr Jelinek
Дата:
Сообщение: Re: pglogical_output - a general purpose logical decoding output plugin