From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Satoshi Nagayasu <snaga(at)uptime(dot)jp> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PARALLEL SAFE/UNSAFE question |
Date: | 2016-07-07 17:29:43 |
Message-ID: | 21680.1467912583@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Satoshi Nagayasu <snaga(at)uptime(dot)jp> writes:
> I was trying writing my own parallel aggregation functions on 9.6beta2.
> During that, we found a bit confusing behavior with SAFE/UNSAFE options.
> Once a PARALLEL UNSAFE function f1_unsafe() is wrapped by
> a PARALLEL SAFE function f1_safe_unsafe(), calling f1_safe_unsafe()
> produces a parallel execution plan despite it implicitly calls
> the UNSAFE FUNCTION f1_unsafe().
> Is this intentional?
Yes. If you mismark the parallel safety of your functions, the
consequences are on your own head. The system can't be expected to
look inside functions to figure out what their actual behavior is.
(See halting problem.)
As things stand, we actually trust the parallel safety marking of
an aggregate itself, though in principle we could look at the markings
of the component functions instead. Again, the expectation is that
the programmer will take care with safety markings.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-07-07 17:51:46 | Re: Bug in batch tuplesort memory CLUSTER case (9.6 only) |
Previous Message | Fujii Masao | 2016-07-07 17:26:42 | Re: EXPLAIN ANALYZE for parallel query doesn't report the SortMethod information. |