Обсуждение: pgsql: Fix a couple of oversights associated with the "physical tlist"
pgsql: Fix a couple of oversights associated with the "physical tlist"
От
tgl@postgresql.org (Tom Lane)
Дата:
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. (Unfortunately the easy-looking fix of calling disuse_physical_tlist during make_sort_xxx doesn't work because in most cases we're already committed to the current input tlist --- it's been marked with sort column numbers, or we've built grouping column numbers using it, etc. The tlist has to be selected properly at the calling level before we start constructing sort-col information. This is easy enough to do, we were just failing to take the point into consideration.) Back-patch to 8.3. I believe the problem probably exists clear back to 7.4 when the physical tlist optimization was added, but I'm afraid to back-patch further than 8.3 without a great deal more study than I want to put into it. The code in this area has drifted a lot over time. The real-world importance of these code paths is uncertain anyway --- I think in many cases we'd probably prefer hash-based methods. Modified Files: -------------- pgsql/src/backend/optimizer/plan: createplan.c (r1.239 -> r1.240) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/createplan.c?r1=1.239&r2=1.240) planner.c (r1.231 -> r1.232) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/planner.c?r1=1.231&r2=1.232) pgsql/src/include/optimizer: planmain.h (r1.106 -> r1.107) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/optimizer/planmain.h?r1=1.106&r2=1.107)
"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!
Gregory Stark <stark@enterprisedb.com> writes: > Does this do the right thing if all the columns in the physical target list > are in fact present in the target list? Yeah, it's pretty much a no-op in that case. regards, tom lane