Which is faster

jasondavis

My script currently selects * from a table that is 62 columns wide on this page I only need 21 of these columns would it be better performance to write them all out? Keep in mind this a high traffic page 300k views a day on it

Piranha

The short anwer is yes.

The long answer involves what kind of data the columns contain, a boolean is quick to transfer but lots of text columns take time. The answer is still probably yes.

Another way to think about this is how it will be in the future. If you add a couple of text columns or big varchar columns you don't have to change anything.

But to know for sure: Test it.

alimadzi

Making sure that your table is properly indexed is probably equally (if not more) important.

NogDog

Most likely it would be faster, since otherwise for each matched row you'll be returning 41 columns of data you don't use. The actual difference will be dependent on how many rows are normally matched and the average amount of data in those additional 41 columns.

jasondavis

Well the etra 40 rows are generaly big and contain users html profile code

Weedpacket

jasondavis wrote:
Well the etra 40 rows are generaly big and contain users html profile code

Well, there you go; lots of data that the DBMS has to retrieve (possibly from additional files depending on how it stores text data and how you've specified the field type) and pipe across to your program, which allocates space to store it, stores it...

...and then ignores.

MarkR

Retrieving more data is likely to be (somewhat) slower. However, don't avoid code reuse to get a small potential performance gain.

Code reuse is good. Developer time is very expensive.

If you can reuse the code which makes the query and/or processes the results, do so. Only worry about the performance of this code if:
You have a real performance problem in your production environment
AND
Your profiling data tells you that this is a place worth optimising.

Mark