Re: Odd system-column handling in postgres_fdw join pushdown patch

Поиск
Список
Период
Сортировка
От Etsuro Fujita
Тема Re: Odd system-column handling in postgres_fdw join pushdown patch
Дата
Msg-id 56F0AF07.2080104@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Odd system-column handling in postgres_fdw join pushdown patch  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Odd system-column handling in postgres_fdw join pushdown patch  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Список pgsql-hackers
On 2016/03/19 4:51, Robert Haas wrote:
> On Thu, Mar 17, 2016 at 7:00 AM, Etsuro Fujita
> <fujita.etsuro@lab.ntt.co.jp> wrote:
>> So, I'd like to propose: (1) when tableoids are
>> requested from the remote server, postgres_fdw sets valid values for
>> them locally, instead (core should support that?)

> Sure.

>> and (2) when any of
>> xmins, xmaxs, cmins, and cmaxs are requested, postgres_fdw gives up
>> pushing down foreign joins.  (We might be able to set appropriate values
>> for them locally the same way as for tableoids, but I'm not sure it's
>> worth complicating the code.)  I think that would be probably OK,
>> because users wouldn't retrieve any such columns in practice.

> Now that seems like the wrong reaction.  I mean, aren't these just
> going to be 0 or something?  Refusing to push the join down seems
> strange.

OK, I'll modify the patch so that the join is pushed down even if any of 
xmins, xmaxs, cmins, and cmaxs are requested.  Do you think which one 
should set values for these as well as tableoids, postgres_fdw or core?

Best regards,
Etsuro Fujita





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

Предыдущее
От: Etsuro Fujita
Дата:
Сообщение: Re: Optimization for updating foreign tables in Postgres FDW
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission denied”