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
|
Список | 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 по дате отправления: