News for hackers. Stuff that matters.
Re:Why SELECT * is bad for SQL performance (2020) by pfarrell on Monday February 15, 2021 @11:19AM (#26144108)
Very true. Also, along those lines, if you have fewer than 10k rows, it’s likely the dB will keep the whole table in memory after the first access, anyway.
Re:Why SELECT * is bad for SQL performance (2020) by jimsmart on Monday February 15, 2021 @11:45AM (#26144349)
In an ideal situation, agreed. But surely that depends entirely on how many tables are being queried (how many tables already exist in the cache), the size of the rows, how much RAM the host has / how big the cache is, plus a few other variables most probably.

What I mean is: like all other things, it depends. And with assumptions like this, it is generally better to measure.

Re:Why SELECT * is bad for SQL performance (2020) by skeeter2020 on Monday February 15, 2021 @11:59AM (#26144504)
he's not really talking about the performance of the DB though, focusing more on size of the resultant payload thatr gets sent over the wire. In the actual database which is traditionally very challenging to scale, projections aren't very expensive. The other things you and GP mention are way more likkely to move the performance needle.