Re: [External] Re: FDW, too long to run explain

Поиск
Список
Период
Сортировка
От Vijaykumar Jain
Тема Re: [External] Re: FDW, too long to run explain
Дата
Msg-id CAE7uO5hLPJDbqY3EpaPjAduoYf7t07snp=bfOH-_BTN=+u9RYA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: FDW, too long to run explain  (auxsvr <auxsvr@gmail.com>)
Ответы Re: [External] Re: FDW, too long to run explain
Список pgsql-general
I am yet to figure out the reason, what we have done is implement fake columns to represent samples and giving them random numbers and keeping other bulls to fake limit.

Most of the queries that were impacted were the ones that did not push order by and limit to foreign servers.
I am also trying to upgrade pg11 to make use of parallelisation.
For now I am making use of materialised view on each shard and using predicates that get pushed directly to ensure a simple plan is created.
There is a compromise but this is what is reasonable for now.

On Sun, 17 Feb 2019 at 4:27 PM auxsvr <auxsvr@gmail.com> wrote:
Related to this question:

Postgresql cursors are in most cases I've tried extremely slow. The cause is as described in my previous answer, in my experience. Is there any plan or way to improve this situation? For example, for FDW one would expect the plan on the remote side to be similar, if not identical, to the one locally, with the exception of the setup cost.
--
Regards,
Peter



--

Regards,
Vijay

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

Предыдущее
От: auxsvr
Дата:
Сообщение: Re: FDW, too long to run explain
Следующее
От: "Ravi Krishna"
Дата:
Сообщение: Re: WSL (windows subsystem on linux) users will need to turn fsync off as of11.2