Re: ERROR: ORDER/GROUP BY expression not found in targetlist
От | Noah Misch |
---|---|
Тема | Re: ERROR: ORDER/GROUP BY expression not found in targetlist |
Дата | |
Msg-id | 20160627023517.GA1329944@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: ERROR: ORDER/GROUP BY expression not found in targetlist (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Mon, Jun 13, 2016 at 03:42:49PM -0400, Tom Lane wrote: > 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. [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. [1] http://www.postgresql.org/message-id/20160527025039.GA447393@tornado.leadboat.com
В списке pgsql-hackers по дате отправления: