Re: Aggregate leads to superfluous projection from the scan

From: Zhihong Yu <zyu(at)yugabyte(dot)com>
To: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Aggregate leads to superfluous projection from the scan
Date: 2022-07-08 17:38:32
Message-ID: CALNJ-vQN-Zy9oqQnK5jEsg3jAX2YqdKJu4jx9akdousOxkVX=g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 8, 2022 at 9:40 AM Zhihong Yu <zyu(at)yugabyte(dot)com> wrote:

> Hi,
> Here is the query which involves aggregate on a single column:
>
>
> https://dbfiddle.uk/?rdbms=postgres_13&fiddle=44bfd8f6b6b5aad34d00d449c04c5a96
>
> 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

Attachment Content-Type Size
index-scan-with-non-returnable.patch application/octet-stream 591 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ibrar Ahmed 2022-07-08 18:09:28 Re: explain analyze rows=%.0f
Previous Message Nathan Bossart 2022-07-08 17:18:48 Re: remove more archiving overhead