>>>>I'm not claiming to be all knowing, but I don't think there are many people having in depth knowledge of the SQL optimizer in the first place. I've spend almost 3 decades optimizing database access, so yes, I like to think I have at least a reasonable level of understanding of what it does,
>>>>
>>>>>2 queries get different query plans. Each plan may have different optimization.
>>>>
>>>>Ok, I'll bite here.
>>>>
>>>>

SELECT *  FROM sometable
>>>>and 
>>>><Pre>SELECT ...full field list ... FROM

>>>>
>>>>Will most likely share the same execution plan as
>>>>1. In both cases the whole table is scanned because there is no WHERE clause
>>>>2. The same field output is requested
>>>>
>>>That was my almost identical 1st thought. Then I began to wonder if this only holds true to "normal", row saving tables or if a columnar data store might introduce differences...
>>
>>The two points would still stand. When you only select a few fields from the table, it becomes a whole different game.
>
>If you are reading a table, different field order probably irrelevant. In a view you might read denormalized structure, some view fields being result of calculations of other table or view fields. Something like a "row field cache" seems logical, but still I wonder if the order of fields asked might introduce differences in access pattern in such a case.

Yes, I agree that the field order almost certainly is irrelevant.
When reading from a view the two points mentioned above still stand.

However, there is one situation come to mind that might make a difference. Our database does use fixed lenght character fields. Returning large number of rows with wide character fields might take up lots of bandwith. Normally this is not really a concern in LAN environments. Our product is optimized to run on high latency WAN network with limited bandwidth. In that case it might be worth to strip off remaining spaces, e.g.

SELECT
      MyField = CAST(RTRIM(MyField) as varchar(100))
      , MyField2 = CAST(RTRIM(MyField2) as varchar(100))
      ...
      FROM Table

We have had some good results by limiting the size of the resultset this way. But on a solid LAN network it is not likely to make a significant impact.

When only selecting a few view fields from a SQL-server view it becomes a total different ballgame. Unlike VFP, SQL server won't bother to calculate fields in the view that in the end are not used, and optimizes the query for the remaining fields. The query might be a full index coverage type of query where the query essentially is ran on an index instead of the table itself.

Walter,