Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sql: try reusing existing renders in GROUP BY #10919

Closed
knz opened this issue Nov 21, 2016 · 4 comments
Closed

sql: try reusing existing renders in GROUP BY #10919

knz opened this issue Nov 21, 2016 · 4 comments
Assignees
Labels
A-sql-optimizer SQL logical planning and optimizations. C-performance Perf of queries or internals. Solution not expected to change functional behavior.
Milestone

Comments

@knz
Copy link
Contributor

knz commented Nov 21, 2016

Found while working on #10799, suggested by @RaduBerinde: when GROUP BY is specified using a column ordinal (e.g. GROUP BY 1) we duplicate the rendered expression in the select node instead of reusing the existing render. This could be perhaps optimized.

@knz knz added C-cleanup Tech debt, refactors, loose ends, etc. Solution not expected to significantly change behavior. C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) labels Nov 21, 2016
@nvanbenschoten
Copy link
Member

Duplicate of #9173?

@knz
Copy link
Contributor Author

knz commented Nov 22, 2016

It's not really a dup but is the dual of that other issue for the groupNode.
I think that #9173 was really specific to sortNode.

@petermattis petermattis added this to the Later milestone Feb 23, 2017
@knz knz added A-sql-optimizer SQL logical planning and optimizations. C-performance Perf of queries or internals. Solution not expected to change functional behavior. and removed C-cleanup Tech debt, refactors, loose ends, etc. Solution not expected to significantly change behavior. C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) labels May 9, 2018
@andy-kimball
Copy link
Contributor

I propose we close this as "won't fix", since it only applies to the heuristic planner (no extra render with cost-based optimizer).

@andy-kimball
Copy link
Contributor

In fact, I'll just go ahead and close it, and if anyone objects, they can reopen. : )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-sql-optimizer SQL logical planning and optimizations. C-performance Perf of queries or internals. Solution not expected to change functional behavior.
Projects
None yet
Development

No branches or pull requests

5 participants