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 по дате отправления: