>>>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.