From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: parallel "return query" is no good |
Date: | 2017-03-23 17:08:16 |
Message-ID: | 20170323170816.6kqgtfkjsdaezrrp@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-03-23 13:03:19 -0400, Robert Haas wrote:
> On Thu, Mar 23, 2017 at 12:50 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > 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 guess the downside of back-patching this is that it could cause a
> plan change for somebody which ends up being worse. On the whole,
> serial execution of queries intended to be run in parallel isn't
> likely to work out well, but it's always possible somebody has a cases
> where it happens to be winning, and this could break it. So maybe I
> should do this only in master? Thoughts?
I'm +0.5 for backpatching.
- Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-03-23 17:14:59 | Re: WIP: Faster Expression Processing v4 |
Previous Message | Stephen Frost | 2017-03-23 17:07:12 | Re: parallel "return query" is no good |