On Sun, Jun 26, 2016 at 10:35 PM, Noah Misch <noah@leadboat.com> wrote:
>> I looked into this and found that the costs are considered fuzzily the
>> same, and then add_path prefers the slightly-worse path on the grounds
>> that it is marked parallel_safe while the MinMaxAgg path is not. It seems
>> to me that there is some fuzzy thinking going on there. On exactly what
>> grounds is a path to be preferred merely because it is parallel safe, and
>> not actually parallelized? Or perhaps the question to ask is whether a
>> MinMaxAgg path can be marked parallel-safe.
>
> [Action required within 72 hours. This is a generic notification.]
>
> The above-described topic is currently a PostgreSQL 9.6 open item ("consider
> whether MinMaxAggPath might fail to be parallel-safe"). Robert, since you
> committed the patch believed to have created it, you own this open item. If
> some other commit is more relevant or if this does not belong as a 9.6 open
> item, please let us know. Otherwise, please observe the policy on open item
> ownership[1] and send a status update within 72 hours of this message.
> Include a date for your subsequent status update. Testers may discover new
> open items at any time, and I want to plan to get them all fixed well in
> advance of shipping 9.6rc1. Consequently, I will appreciate your efforts
> toward speedy resolution. Thanks.
It turns out that this open item is phased incorrectly. I'll update
the phrasing.
/* A MinMaxAggPath implies use of subplans, so cannot be
parallel-safe */ pathnode->path.parallel_safe = false;
Currently, MinMaxAggPath is never parallel-safe; the question is
whether we could allow it to be parallel-safe (not, as the current
phrasing implies, whether it might ever need to be other than
parallel-safe). It appears to me that the answer is "no", because a
MinMaxAggPath contains a list of MinMaxAggInfo objects, and there we
have this:
Param *param; /* param for subplan's output */
Since subplans aren't passed down to parallel workers, no
MinMaxAggPath can be parallel-safe. Therefore, I think there's
nothing to do here right now. Comments?
See also https://www.postgresql.org/message-id/CA+TgmoZ7wvMPMTSNtk+dfDUNWmc8kK5pUtLDnzOLvJ9DVeAF_A@mail.gmail.com
(Official status update: I'll remove this open item in 3 days unless
the above analysis is shown to be incorrect.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
