Why SELECT * is bad for SQL performance (2020)

Re:Why SELECT * is bad for SQL performance (2020) by GekkePrutser on Monday February 15, 2021 @06:33AM (#26141733)

I agree wildcards are better avoided but so are column orders in result extraction. They are a source of bugs and much review work when changes are made.

If I had to choose (which usually isn't necessary) I'd say wildcards are the lesser evil.

[ Parent | on HN ]

Re:Why SELECT * is bad for SQL performance (2020) by rbut on Monday February 15, 2021 @07:10AM (#26141978)

I agree. Applications that rely on the ordering of columns are as bad as people who complain when I add a new column into, or change the ordering of a CSV which has column headers. There is no technical reason to do this; computers are ample fast enough to look up columns by name!

[ Parent | on HN ]

Re:Why SELECT * is bad for SQL performance (2020) by csharptwdec19 on Monday February 15, 2021 @08:41AM (#26142633)

>computers are ample fast enough to look up columns by name!

Sure, but depending on number of records and/or implementation of the name lookup, it can add up over a large resultset, or have a slightly cost over many smaller queries.

Mind you, I think -most- implementations are smart enough to only need to do the lookup once for a returned datareader, but the cost is still there.

[ Parent | on HN ]

Re:Why SELECT * is bad for SQL performance (2020) by nkozyra on Monday February 15, 2021 @07:20AM (#26142038)

> so are column orders in result extraction.

While I agree, there are some languages + db drivers where this is your only choice unless you roll your own. Go's sql package relies on order in the Scan method, for example.

[ Parent | on HN ]

Re:Why SELECT * is bad for SQL performance (2020) by 867-5309 on Monday February 15, 2021 @07:07AM (#26141963)

it's becoming increasingly more common to sort columns at the application layer

[ Parent | on HN ]