Re: Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat
Дата
Msg-id CA+Tgmoa80ZmsSYynOinCF3zzqx5kLE6Eetj3GE=hRPCV5tXB-w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Ответы Re: Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Mar 16, 2016 at 4:10 AM, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote:

Now what's going on here?  It seems to me that either postgres_fdw
requires a user mapping (in which case this ought to fail) or it
doesn't (in which case this ought to push the join down).  I don't
understand how working but not pushing the join down can ever be the
right behavior.
In 9.5, postgres_fdw allowed to prepare statements involving foreign tables without an associated user mapping as long as planning did not require the user mapping. Remember, planner would require user mapping in case use_remote_estimate is ON for that foreign table. The user mapping would be certainly required at the time of execution. So executing such a prepared statement would throw error. If somebody created a user mapping between prepare and execute, execute would not throw an error. A join can be pushed down only when user mappings associated with the joining relations are known and they match. But given the behavior of 9.5 we should let the prepare succeed, even if the join can not be pushed down because of unknown user mapping. Before this fix, the test was not letting the prepare succeed, which is not compliant with 9.5.

If a query against a single table with no user mapping is legal, I don't see why pushing down a join between two tables neither of which has a user mapping shouldn't also be legal.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

Предыдущее
От: David Steele
Дата:
Сообщение: Re: [PATH] Jsonb, insert a new value into an array at arbitrary position
Следующее
От: David Steele
Дата:
Сообщение: Re: PATCH: index-only scans with partial indexes