When you hit the rock bottom, remember that at the very least you're better than those who use * in SQL selects bc they're too lazy to specify the fields they need.

but.... what if i DO need all the fields? ;)

@tosensei AFAIK is still faster to specify them ( I mean in execution time )

@We3D is there a benchmark for this? Why would specifying 50 columns manually has better performance than simply stating * ? Won't the parser waste a lot of time checking all those column names?

@daniel-wu
https://stackoverflow.com/questions...

apart from the top answer you can check the one with 44 ups, but couldn't find a specific benchmark

I was such lazy. But since I write C I want everything described. I'm not lazy to type anymore (uses codeium *kuch**kuch*)

@daniel-wu yeah, but else he had to search the 50 fields himself. It's less lexing if you use *. I think it's almost not to benchmark, very minimum

Most queries I run are for just getting something then and there, why would I bother to specify each column? Wasting seconds to shave milliseconds off a query..

As always, it depends. But it's not about lazyness.

Why would write it out be faster than without it?

The database has to decide if it eliminates the projection in its query optimizer and if it is * it can always eliminate the projection. If it is all fields, it has to compare it to the columns present to figure out if all columns are named and can conly eliminate it then.

This is technically an O(n) effort, but since n is the amount of columns and normally the amount of columns is so much smaller than m, which is the amount of rows, so that n << m, we can say it is ≈ O(1). So, in the end, it shouldn't matter.