Re: assessing parallel-safety

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: assessing parallel-safety
Date: 2015-03-19 13:35:14
Message-ID: CAA4eK1JAnYQkVXB_piOUSyVQWf7y1BSbwKaBXg9vShzd94MWcg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 18, 2015 at 10:53 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Sun, Feb 15, 2015 at 6:24 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> > It's important for parallelism to work under the extended query
protocol, and
> > that's nontrivial. exec_parse_message() sets cursorOptions.
> > exec_bind_message() runs the planner. We don't know if a parallel plan
is
> > okay before seeing max_rows in exec_execute_message().
>
> Yes, that's a problem. One could require users of the extended query
> protocol to indicate their willingness to accept a parallel query plan
> when sending the bind message by setting the appropriate cursor
> option; and one could, when that option is specified, refuse execute
> messages with max_rows != 0. However, that has the disadvantage of
> forcing all clients to be updated for the new world order.

Another way could be when max_rows != 0, then inform executor to
just execute the plan locally, which means run the parallel seq scan
node in master only. We already need to do the same when no workers
are available at the time of execution.

I think we can inform executor by setting this information in Estate
during ExecutorRun.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thom Brown 2015-03-19 14:07:35 Re: GSoC 2015: Extra Jsonb functionality
Previous Message Dmitry Dolgov 2015-03-19 13:23:10 Re: GSoC 2015: Extra Jsonb functionality