From: | Satoshi Nagayasu <snaga(at)uptime(dot)jp> |
---|---|
To: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | PARALLEL SAFE/UNSAFE question |
Date: | 2016-07-06 22:35:03 |
Message-ID: | CAA8sozefPOjcjkhS5JtOE2kQa_Wpkygdx27yjDftcJX7beoi+Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi all,
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?
Please take a look at our example here:
https://gist.github.com/snaga/362a965683fb2581bc693991b1fcf721
According to the manual[1], it is described as:
> the presence of such a function in an SQL statement forces a serial execution plan.
so, I expected that calling UNSAFE functions should produce
a non-parallel execution plan even wrapped in SAFE functions.
Is this a sort of limitations? Is this working correctly as we expected?
Regards,
[1] https://www.postgresql.org/docs/9.6/static/sql-createfunction.html
--
Satoshi Nagayasu <snaga(at)uptime(dot)jp>
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2016-07-06 22:51:41 | Re: Password identifiers, protocol aging and SCRAM protocol |
Previous Message | Andres Freund | 2016-07-06 22:06:13 | Re: Reviewing freeze map code |