On 31 October 2014 18:47, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Oct 31, 2014 at 11:02 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> You mentioned earlier that functions would need to be marked proisparallel etc..
>>
>> What conditions will that be protecting against? If we aren't going to
>> support the general case where every single thing works, can we at
>> least discuss what the list of cases is that we will support.
>
> In general, any operation that relies on backend-private state not
> shared with a cooperating backend isn't parallel-safe. For example,
Yes, the principle is easy to understand, but that was not the question.
You are saying that placing restrictions on which functions can
execute is necessary, yet at the same time saying that we must have
generalised locking for workers because restrictions on locking are
not acceptable. I don't point that out because I want an argument or
to prove a point, but because there are important things on the table
here.
What are the specific restrictions you are suggesting we place on
parallel workers? We need that definition clear so we can decide how
to mark the functions. If we don't know, which is easily
understandable, then the best way to find that out is to build a
restricted solution and to expand slowly outwards to find problems.
An obvious milestone there is whether a function contains SQL, which
is the point chosen by some other databases. I personally hope to
expand upon that, but it would be useful to reach it first and then
continue from there.
I was already thinking of implementing CONTAINS NO SQL as a SQL
Standard function marking since it can be used to optimize COPY
further.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
