MinMaxAggPath vs. parallel-safety

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila(at)enterprisedb(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: MinMaxAggPath vs. parallel-safety
Date: 2016-06-27 19:11:07
Message-ID: CA+TgmobPvgBoKR+yEej57eZnUuNdmy_U_-yLDntHSPvN4wXFOQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 26, 2016 at 10:35 PM, Noah Misch <noah(at)leadboat(dot)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-06-27 19:25:37 fixing consider_parallel for upper planner rels
Previous Message Alex Malek 2016-06-27 18:27:32 Re: problems using pg_start_backup/pg_stop_backup and pg_basebackup at same time