Re: ERROR: ORDER/GROUP BY expression not found in targetlist

I wrote:
> ... there was also an unexplainable plan change:

> *** /home/postgres/pgsql/src/test/regress/expected/aggregates.out Thu Apr 7 21:13:14 2016
> --- /home/postgres/pgsql/src/test/regress/results/aggregates.out Mon Jun 13 11:54:01 2016
> ***************
> *** 577,590 ****

> explain (costs off)
> select max(unique1) from tenk1 where unique1 > 42000;
> ! QUERY PLAN
> ! ---------------------------------------------------------------------------
> ! Result
> ! InitPlan 1 (returns $0)
> ! -> Limit
> ! -> Index Only Scan Backward using tenk1_unique1 on tenk1
> ! Index Cond: ((unique1 IS NOT NULL) AND (unique1 > 42000))
> ! (5 rows)

> select max(unique1) from tenk1 where unique1 > 42000;
> max
> --- 577,588 ----

> explain (costs off)
> select max(unique1) from tenk1 where unique1 > 42000;
> ! QUERY PLAN
> ! ----------------------------------------------------
> ! Aggregate
> ! -> Index Only Scan using tenk1_unique1 on tenk1
> ! Index Cond: (unique1 > 42000)
> ! (3 rows)

> select max(unique1) from tenk1 where unique1 > 42000;
> max

> I would not be surprised at a change to a parallel-query plan, but there's
> no parallelism here, so what happened? This looks like a bug to me.
> (Also, doing this query without COSTS OFF shows that the newly selected
> plan actually has a greater estimated cost than the expected plan, which
> makes it definitely a bug.)

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.

regards, tom lane