[resending because the first went to -committers which is kind of bogus]
"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!
