[HACKERS] parallel "return query" is no good
От | Robert Haas |
---|---|
Тема | [HACKERS] parallel "return query" is no good |
Дата | |
Msg-id | CA+TgmoZ_ZuH+auEeeWnmtorPsgc_SmP+XWbDsJ+cWvWBSjNwDQ@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: [HACKERS] parallel "return query" is no good
|
Список | pgsql-hackers |
Commit 7aea8e4f2daa4b39ca9d1309a0c4aadb0f7ed81b allowed a parallel plan to be generated when for a RETURN QUERY or RETURN QUERY EXECUTE statement in a PL/pgsql block. As it turns out, the analysis that led to this decision was totally wrong-headed, because the plan will always be executed using SPI_cursor_fetch(portal, true, 50), which will cause ExecutePlan() to get invoked with a count of 50, which will cause it to run the parallel plan serially, without workers. Therefore, passing CURSOR_OPT_PARALLEL_OK is a bad idea here; all it can do is cause us to pick a parallel plan that's slow when executed serially instead of the best serial plan. The attached patch fixes it. I plan to commit this and back-patch it to 9.6, barring objections or better ideas. I previously remarked on this in http://postgr.es/m/CA+TgmobXEhvHbJtWDuPZM9bVSLiTj-kShxQJ2uM5GPDze9fRYA@mail.gmail.com but I wasn't quite so clear what the whole picture was in that email as I am now. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: