Re: Postgres_fdw join pushdown - getting server crash in left outer join of three table

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Postgres_fdw join pushdown - getting server crash in left outer join of three table
Дата
Msg-id CAB7nPqQCDUAa-D-4hZyWY2EDnp+Dwjdx+pVgPh6hWPAgL_AMOA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Postgres_fdw join pushdown - getting server crash in left outer join of three table  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Список pgsql-hackers
On Mon, Mar 21, 2016 at 11:32 PM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
>> In get_useful_ecs_for_relation, it seems to me that this assertion
>> should be removed and replaces by an actual check because even if
>> right_ec and left_ec are initialized, we cannot be sure that ec_relids
>> contains the relations specified:
>>         /*
>>          * restrictinfo->mergeopfamilies != NIL is sufficient to guarantee
>>          * that left_ec and right_ec will be initialized, per comments in
>>          * distribute_qual_to_rels, and rel->joininfo should only contain
>> ECs
>>          * where this relation appears on one side or the other.
>>          */
>>         if (bms_is_subset(relids, restrictinfo->right_ec->ec_relids))
>>             useful_eclass_list =
>> list_append_unique_ptr(useful_eclass_list,
>>
>> restrictinfo->right_ec);
>>         else
>>         {
>>             Assert(bms_is_subset(relids,
>> restrictinfo->left_ec->ec_relids));
>>             useful_eclass_list =
>> list_append_unique_ptr(useful_eclass_list,
>>
>> restrictinfo->left_ec);
>>         }
>
> An EC covers all the relations covered by all the equivalence members it
> contains. In case of mergejoinable clause for outer join, EC may cover just
> a single relation whose column appears on either side of the clause. In this
> case, bms_is_subset() for a given join relation covering single relation in
> EC will be false. So, we have to use bms_overlap() instead of
> bms_is_subset(). The caller get_useful_pathkeys_for_rel() extracts the
> equivalence member (if any), which is entirely covered by the given
> relation. Otherwise, you are correct that we have to convert the assertion
> into a condition. I have added comments in get_useful_ecs_for_relation()
> explaining, why.

Ah, OK. Thanks for the explanation. This code is fixing the problem
for me as well here.
(note to self: study more the planner code).
-- 
Michael



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: BRIN is missing in multicolumn indexes documentation
Следующее
От: Eduardo Morras
Дата:
Сообщение: [PROPOSAL] Add SCTP network protocol to postgresql backend and frontend