Re: [HACKERS] why not parallel seq scan for slow functions

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] why not parallel seq scan for slow functions
Дата
Msg-id CA+TgmoY409erwRzj-pBeE1vzD2dafBFiqWw8dNS5Uu8kdjVefg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] why not parallel seq scan for slow functions  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: [HACKERS] why not parallel seq scan for slow functions  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Sat, Aug 12, 2017 at 9:18 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> I think skipping a generation of gather paths for scan node or top
> level join node generated via standard_join_search seems straight
> forward, but skipping for paths generated via geqo seems to be tricky
> (See use of generate_gather_paths in merge_clump).  Assuming, we find
> some way to skip it for top level scan/join node, I don't think that
> will be sufficient, we have some special way to push target list below
> Gather node in apply_projection_to_path, we need to move that part as
> well in generate_gather_paths.

I don't think that can work, because at that point we don't know what
target list the upper node wants to impose.

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



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] scan on inheritance parent with no children in current session
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90