Which is quicker - SELECT * or SELECT field1, field2...

[Dave Addey]

Well, I went through and set the code to select just the ones it needs - but
there was no sign of a speed increase, so I'll stick with SELECT * for now.
In fact, it kind of ended up slowing things down, as my code to calculate
the field names was taking a while!

Thanks for the advice,

Dave.

> From: "Sims, John" <ayu8 at cdc.gov>
> Reply-To: Valentina Developers <valentina at lists.macserve.net>
> Date: Wed, 14 Dec 2005 13:37:51 -0500
> To: Valentina Developers <valentina at lists.macserve.net>
> Conversation: Which is quicker - SELECT * or SELECT field1, field2...
> Subject: RE: Which is quicker - SELECT * or SELECT field1, field2...
> 
> 
>> -----Original Message-----
>> From: valentina-bounces at lists.macserve.net
>> [mailto:valentina-bounces at lists.macserve.net] On Behalf Of Dave Addey
>> Sent: Wednesday, December 14, 2005 1:24 PM
>> To: Valentina Developers
>> Subject: Which is quicker - SELECT * or SELECT field1, field2...
>> 
>> Another question:
>> 
>> If I only need half of the fields in a table, which should be
>> quicker ­ SELECT * or SELECT fieldname1, fieldname2, [...],
>> fieldnameN?
>> 
>> I figure that * has to select more, but doesn¹t have to do
>> any working out of what to select.  Does this make it quicker?
>> 
>> How about SELECT ** vs SELECT fieldname1, fieldname2, [...],
>> fieldnameN?
>> 
>> V4RB 2.0.5, RB 5.5.5, Mac OS 10.4.3, Mach-O compile, local
>> database only.
>> 
>> Thanks for all the help ­ I¹m nearly there!
>> 
>> Dave. 
> 
> Hi Dave,
> 
> A general rule of thumb for SQL is to only ask for what you need, although
> that rule really tends to apply more to client/server environments to limit
> the amount of data going back and forth along "the pipe".  My advice would be
> to follow this rule even for local databases solely for the "consider the
> future" aspect.  You may be local now, but as time goes by you may find that
> you eventually take your app to the next level and make it client/server.  As
> far as which is faster internally for Valentina, that we'll have to leave to
> Ruslan to answer :-)
> 
> Take care,
> 
> -John 
> _______________________________________________
> Valentina mailing list
> Valentina at lists.macserve.net
> http://lists.macserve.net/mailman/listinfo/valentina