Re: Aggregate leads to superfluous projection from the scan

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Aggregate leads to superfluous projection from the scan
Дата
Msg-id 3535103.1657322369@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Aggregate leads to superfluous projection from the scan  (Zhihong Yu <zyu@yugabyte.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: doc: pg_prewarm add configuration example
Следующее
От: Yura Sokolov
Дата:
Сообщение: Re: [PATCH] fix wait_event of pg_stat_activity in case of high amount of connections