Re: Aggregate leads to superfluous projection from the scan

Поиск
Список
Период
Сортировка
От Zhihong Yu
Тема Re: Aggregate leads to superfluous projection from the scan
Дата
Msg-id CALNJ-vQN-Zy9oqQnK5jEsg3jAX2YqdKJu4jx9akdousOxkVX=g@mail.gmail.com
обсуждение исходный текст
Ответ на Aggregate leads to superfluous projection from the scan  (Zhihong Yu <zyu@yugabyte.com>)
Ответы Re: Aggregate leads to superfluous projection from the scan  (Ibrar Ahmed <ibrar.ahmad@gmail.com>)
Список pgsql-hackers


On Fri, Jul 8, 2022 at 9:40 AM Zhihong Yu <zyu@yugabyte.com> wrote:
Hi,
Here is the query which involves aggregate on a single column:


As you can see from `Output:`, there are many columns added which are not needed by the query executor.

I wonder if someone has noticed this in the past.
If so, what was the discussion around this topic ?

Thanks
Hi,
With the patch, I was able to get the following output:

 explain (analyze, verbose) /*+ IndexScan(t) */select count(fire_year) from fires t where objectid <= 2000000;
                                                              QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=119.00..119.01 rows=1 width=8) (actual time=9.453..9.453 rows=1 loops=1)
   Output: count(fire_year)
   ->  Index Scan using fires_pkey on public.fires t  (cost=0.00..116.50 rows=1000 width=4) (actual time=9.432..9.432 rows=0 loops=1)
         Output: fire_year
         Index Cond: (t.objectid <= 2000000)
 Planning Time: 52.598 ms
 Execution Time: 13.082 ms

Please pay attention to the column list after `Output:`

Tom:
Can you take a look and let me know what I may have missed ?

Thanks
Вложения

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

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: remove more archiving overhead
Следующее
От: Ibrar Ahmed
Дата:
Сообщение: Re: explain analyze rows=%.0f