Re: Push down more full joins in postgres_fdw
От | Ashutosh Bapat |
---|---|
Тема | Re: Push down more full joins in postgres_fdw |
Дата | |
Msg-id | CAFjFpRcNy8V5oQkMdpPi3Q-bwReJofUoo-U3CVu34OKbWWcGAA@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 1:05 PM, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote: > On 2016/09/15 15:29, Ashutosh Bapat wrote: >> >> On Wed, Sep 14, 2016 at 8:52 PM, Robert Haas <robertmhaas@gmail.com> >> wrote: > > >>> I'm not sure why it wouldn't work >>> to just use the lowest RTI involved in the join, though; the others >>> won't appear anywhere else at that query level. > > >> So +1 for >> using the smallest RTI to indicate a subquery. > > > +1 for the general idea. > > 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. We might differentiate between a base relation alias and subquery alias by using different prefixes like "r" and "s" resp. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
В списке pgsql-hackers по дате отправления: