Re: Parallel execution and prepared statements

Поиск
Список
Период
Сортировка
От Tobias Bussmann
Тема Re: Parallel execution and prepared statements
Дата
Msg-id 95EE0F03-0341-41F0-891C-19631C2B6E24@gmx.net
обсуждение исходный текст
Ответ на Re: Parallel execution and prepared statements  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Parallel execution and prepared statements
Список pgsql-hackers
> Yeah, we could do something like this, perhaps not in exactly this
> way, but I'm not sure it's a good idea to just execute the parallel
> plan without workers.

sure, executing parallel plans w/o workers seems a bit of a hack. But:
- we already do it this way in some other situations
- the alternative in this special situation would be to _force_ replanning without the CURSOR_OPT_PARALLEL_OK. The
decisionfor replanning is hidden deep within plancache.c and while we could influence it with CURSOR_OPT_CUSTOM_PLAN
thiswouldn't have an effect if the prepared statement doesn't have any parameters. Additionally, influencing the
decisionand generating a non-parallel plan would shift the avg cost calculation used to choose custom or generic plans. 

Maybe someone can come up with a better idea for a solution. These three approaches are all I see so far.

Best regards,
Tobias Bussmann


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Unlogged tables cleanup
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Assignment of valid collation for SET operations on queries with UNKNOWN types.