Re: pgsql: Fix a couple of oversights associated with the "physical tlist"
От | Gregory Stark |
---|---|
Тема | Re: pgsql: Fix a couple of oversights associated with the "physical tlist" |
Дата | |
Msg-id | 87fxtkaujd.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | pgsql: Fix a couple of oversights associated with the "physical tlist" (tgl@postgresql.org (Tom Lane)) |
Ответы |
Re: pgsql: Fix a couple of oversights associated with the "physical tlist"
|
Список | pgsql-committers |
"Tom Lane" <tgl@postgresql.org> writes: > Log Message: > ----------- > Fix a couple of oversights associated with the "physical tlist" optimization: > we had several code paths where a physical tlist could be used for the input > to a Sort node, which is a dumb idea because any unneeded table columns will > increase the volume of data the sort has to push around. + /* Detect if we'll need an explicit sort for grouping */ + if (parse->groupClause && !use_hashed_grouping && + !pathkeys_contained_in(group_pathkeys, current_pathkeys)) + { + need_sort_for_grouping = true; + /* + * Always override query_planner's tlist, so that we don't + * sort useless data from a "physical" tlist. + */ + need_tlist_eval = true; + } Does this do the right thing if all the columns in the physical target list are in fact present in the target list? Is it going to force us to do extra work to reconstruct the same data? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!
В списке pgsql-committers по дате отправления: