Re: How and at what stage to stop FDW to generate plan with JOIN.

Поиск
Список
Период
Сортировка
От Ibrar Ahmed
Тема Re: How and at what stage to stop FDW to generate plan with JOIN.
Дата
Msg-id CALtqXTcXaBZTr5Y3TzTfnqPAVdtAkUpPDSfeKWcY2SGm51AWGA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: How and at what stage to stop FDW to generate plan with JOIN.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers


On Wed, Apr 24, 2019 at 1:15 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Ibrar Ahmed <ibrar.ahmad@gmail.com> writes:
> I am working on an FDW where the database does not support any operator
> other than "=" in JOIN condition. Some queries are genrating the plan with
> JOIN having "<" operator. How and at what stage I can stop FDW to not make
> such a plan. Here is my sample query.

What exactly do you think should happen instead?  You can't just tell
users not to ask such a query.  (Well, you can try, but they'll probably
go looking for a less broken FDW.)

I know that.
 
If what you really mean is you don't want to generate pushed-down
foreign join paths containing non-equality conditions, the answer is
to just not do that.  That'd be the FDW's own fault, not that of
the core planner, if it creates a path representing a join it
can't actually implement.  You'll end up running the join locally,
which might not be great, but if you have no other alternative
then that's what you gotta do.

Yes, that's what I am thinking. In case of non-equality condition join them locally is
the only solution. I was just confirming.
 
If what you mean is you don't know how to inspect the join quals
to see if you can implement them, take a look at postgres_fdw
to see how it handles the same issue.

I really don't know postgres_fdw have the same issue, but yes postgres_fdw 
is always my starting point. 
 
                        regards, tom lane


--
Ibrar Ahmed

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: How and at what stage to stop FDW to generate plan with JOIN.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6