Why SELECT * is bad for SQL performance (2020)

Re:Why SELECT * is bad for SQL performance (2020) by sk5t on Monday February 15, 2021 @11:13AM (#26144044)

> “Select ” will almost certainly be optimized away by the execution plan
What do you mean? Ask for all the columns, you're gonna get all the columns in a resultset. Only in a subquery could the planner know what is unused.

'select ' is _perhaps_ tolerable for creating a view--under the conditions that the database transforms the query into the unambiguous named columns at view creation time--and that's about it.

[ Parent | on HN ]

Re:Why SELECT * is bad for SQL performance (2020) by pfarrell on Monday February 15, 2021 @11:23AM (#26144154)

You’re right. When I wrote that, I was thinking higher up the chain in an orm layer. Sending “select *” to the db can’t be “optimized away” at that layer, it will have to return all the columns. Unless, like you said, the scope of the “select *” contains it in a sub query where the columns used can be known... “it depends :)”

[ Parent | on HN ]