Re: Push down more full joins in postgres_fdw
От | Ashutosh Bapat |
---|---|
Тема | Re: Push down more full joins in postgres_fdw |
Дата | |
Msg-id | CAFjFpRfb_AGq=AnCS2ZUMW04MWBbFxT9ws=TZ=U3VXR_Pq1GZw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Push down more full joins in postgres_fdw (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: Push down more full joins in postgres_fdw
|
Список | pgsql-hackers |
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. That hash table is just for fast lookup. See > build_join_rel. Sorry, I wasn't clear in my reply. 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. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
В списке pgsql-hackers по дате отправления: