Re: Push down more full joins in postgres_fdw

Поиск
Список
Период
Сортировка
От Etsuro Fujita
Тема Re: Push down more full joins in postgres_fdw
Дата
Msg-id ddca90d5-6fa9-b959-90ae-905ba8005ab9@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Push down more full joins in postgres_fdw  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Ответы Re: Push down more full joins in postgres_fdw  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Список pgsql-hackers
On 2016/09/26 18:06, Ashutosh Bapat wrote:
> On Mon, Sep 26, 2016 at 1:05 PM, Etsuro Fujita
> <fujita.etsuro@lab.ntt.co.jp> wrote:

>> ISTM that the use of the same RTI for subqueries in multi-levels in a remote
>> SQL makes the SQL a bit difficult to read.  How about using the position of
>> the join rel in join_rel_list, (more precisely, the position plus
>> list_length(root->parse->rtable)), instead?

> We switch to hash table to maintain the join RelOptInfos when the
> number of joins grows larger, where the position won't make much
> sense.

That's right, but we still store the joinrel into join_rel_list after 
creating that hash table.  That hash table is just for fast lookup.  See 
build_join_rel.

> We might differentiate between a base relation alias and
> subquery alias by using different prefixes like "r" and "s"  resp.

Hmm.  My concern about that would the recursive use of "s" with the same 
RTI as subquery aliases for different level subqueries in a single 
remote SQL.  For example, if those subqueries include a base rel with 
RTI=1, then "s1" would be used again and again within that SQL.  That 
would be logically correct, but seems confusing to me.

Best regards,
Etsuro Fujita





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

Предыдущее
От: Kuntal Ghosh
Дата:
Сообщение: Re: wal_segment size vs max_wal_size
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Push down more full joins in postgres_fdw