Re: Foreign join pushdown vs EvalPlanQual

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Foreign join pushdown vs EvalPlanQual
Дата
Msg-id CAB7nPqT=9wQkVCWkFZ=JMZ4rLGtQHPWt-ysk_jFHP5qHgRUp6A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Foreign join pushdown vs EvalPlanQual  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Foreign join pushdown vs EvalPlanQual  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
On Thu, Dec 10, 2015 at 1:32 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Dec 9, 2015 at 3:22 AM, Etsuro Fujita
> <fujita.etsuro@lab.ntt.co.jp> wrote:
>> Sorry, my explanation might be not enough, but I'm not saying to hide the
>> subplan.  I think it would be better to show the subplan somewhere in the
>> EXPLAIN outout, but I'm not sure that it's a good idea to show that in the
>> current form.  We have two plan trees; one for normal query execution and
>> another for EvalPlanQual testing.  I think it'd be better to show the
>> EXPLAIN output the way that allows users to easily identify each of the plan
>> trees.
>
> It's hard to do that because we don't identify that internally
> anywhere.  Like I said before, the possibility of a ForeignScan having
> an outer subplan is formally independent of the new EPQ stuff, and I'd
> prefer to maintain that separation and just address this with
> documentation.

Fujita-san, others, could this be addressed with documentation?

> Getting this bug fixed has been one of the more exhausting experiences
> of my involvement with PostgreSQL, and to be honest, I think I'd like
> to stop spending too much time on this now and work on getting the
> feature that this is intended to support working.  Right now, the only
> people who can have an opinion on this topic are those who are
> following this thread in detail, and there really aren't that many of
> those.

I am numbering that to mainly 3 people, you included :)

> If we get the feature - join pushdown for postgres_fdw -
> working, then we might get some feedback from users about what they
> like about it or don't, and certainly if this is a frequent complaint
> then that bolsters the case for doing something about it, and possibly
> also helps us figure out what that thing should be.  On the other
> hand, if we don't get the feature because we're busy debating
> interface details related to this patch, then none of these details
> matter anyway because nobody except developer is actually running the
> code in question.

As this debate continues, I think that moving this patch to the next
CF would make the most sense then.. So done this way.
-- 
Michael



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Patch: Implement failover on libpq connect level.
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: custom function for converting human readable sizes to bytes