Re: Push down more full joins in postgres_fdw
От | Etsuro Fujita |
---|---|
Тема | Re: Push down more full joins in postgres_fdw |
Дата | |
Msg-id | 2567405b-6d74-484c-34f6-601b347e8445@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
|
Список | pgsql-hackers |
On 2016/09/26 20:20, Ashutosh Bapat wrote: > On Mon, Sep 26, 2016 at 4:06 PM, Etsuro Fujita > <fujita.etsuro@lab.ntt.co.jp> wrote: >> 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. > As the list grows, it will take > longer to locate the RelOptInfo of the given join. Doing that for > creating an alias seems an overkill. The join rel is appended to the end of the list, so I was thinking to get the position info by list_length during postgresGetForeignJoinPaths. Best regards, Etsuro Fujita
В списке pgsql-hackers по дате отправления: