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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ERROR: ORDER/GROUP BY expression not found in targetlist
Дата
Msg-id 1597.1465846969@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ERROR: ORDER/GROUP BY expression not found in targetlist  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: ERROR: ORDER/GROUP BY expression not found in targetlist  (Robert Haas <robertmhaas@gmail.com>)
Re: ERROR: ORDER/GROUP BY expression not found in targetlist  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "'bruce@momjian.us'"
Дата:
Сообщение: Re: Prepared statements and generic plans
Следующее
От: Tom Lane
Дата:
Сообщение: Re: New design for FK-based join selectivity estimation