Re:Why SELECT * is bad for SQL performance (2020)
by VBprogrammer on Monday February 15, 2021 @12:06PM
(#26144584)
And the rub is if you fail to apply it liberally enough you end up with no completed software or difficult to maintain software because someone went around applying every micro-optimisation in the book regardless of how nessasary or appropriate it might be.
Re:Why SELECT * is bad for SQL performance (2020)
by vp8989 on Monday February 15, 2021 @02:14PM
(#26146047)
"someone went around applying every micro-optimisation in the book regardless of how nessasary or appropriate it might be"
This feels like a strawman. I have yet to see an instance of this in my 10 years. The much, much, much more common case is people justifying half-assed shoddy work with YAGNI.
Re:Why SELECT * is bad for SQL performance (2020)
by randallsquared on Monday February 15, 2021 @02:58PM
(#26146565)
Survivorship bias suggests we're more likely to see projects that resulted in released software...
Re:Why SELECT * is bad for SQL performance (2020)
by sombremesa on Monday February 15, 2021 @02:44PM
(#26146392)
See: solo indie gamedevs that build their own engines for years and subsequently fail to release anything.
Re:Why SELECT * is bad for SQL performance (2020)
by autra on Monday February 15, 2021 @04:24PM
(#26147637)
Fortunately, stars in sql are also really bad for maintenance ;-) So I guess there is indeed no reason to use them!
Re:Why SELECT * is bad for SQL performance (2020)
by BurningFrog on Monday February 15, 2021 @02:37PM
(#26146311)
I work that way, and I don't end up slow, shitty software.
I do end up shipping working software much sooner than if I optimized every statement everywhere.
When you constantly apply this "only things bigger than X matter" reasoning you still end up with slow, shitty software but you just died by a thousand cuts instead of 1.