Re: Aggregate leads to superfluous projection from the scan - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Aggregate leads to superfluous projection from the scan
Date
Msg-id 3535103.1657322369@sss.pgh.pa.us
Whole thread Raw
In response to Re: Aggregate leads to superfluous projection from the scan  (Zhihong Yu <zyu@yugabyte.com>)
List pgsql-hackers
Zhihong Yu <zyu@yugabyte.com> writes:
> I was looking at the following comment in createplan.c :

>      * For table scans, rather than using the relation targetlist (which is
>      * only those Vars actually needed by the query), we prefer to generate
> a
>      * tlist containing all Vars in order.  This will allow the executor to
>      * optimize away projection of the table tuples, if possible.

> Maybe you can give me some background on the above decision.

Look into execScan.c and note that it skips doing ExecProject() if the
scan node's targetlist exactly matches the table's tuple descriptor.
And particularly this comment:

 * We can avoid a projection step if the requested tlist exactly matches
 * the underlying tuple type.  If so, we just set ps_ProjInfo to NULL.
 * Note that this case occurs not only for simple "SELECT * FROM ...", but
 * also in most cases where there are joins or other processing nodes above
 * the scan node, because the planner will preferentially generate a matching
 * tlist.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: doc: pg_prewarm add configuration example
Next
From: Yura Sokolov
Date:
Subject: Re: [PATCH] fix wait_event of pg_stat_activity in case of high amount of connections