Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.databases.ms-sqlserver    |    Notorious Rube Goldberg contraption    |    19,505 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 17,768 of 19,505    |
|    Gert-Jan Strik to jbdhl    |
|    Re: When are projections done?    |
|    02 Mar 10 22:23:14    |
      a147ed41       From: sorrytoomuchspamalready@xs4all.nl              jbdhl wrote:       >       > Consider a table and a query referring to only a subset of the columns       > in that table. How early in the query evaluation is the projection       > carried out?       >       > Are the columns to be selected filtered out as early as in the very       > access method that reads the table rows from the buffer, or are the       > projection handled later, after the whole row has been fetched by the       > access method?       >       > Does it depend on the complexity of the query, how far down the three       > that the projection is handled out?       >       > Thanks!              In general, the optimizer is written to parse, compile and execute a       query as fast as possible. As a rule it will cut out every unnecessary       part that is possible, as long as there is a gain in the end, and it       will try to do so as early as possible.              Typically, the operator that locates the rows will also read the table       data. The exceptions are operators like index joining or index       intersection.              Of course, the storage engine will only fetch the columns that are       needed to process the query. However, since the relative cost is low       (mainly memory space for intermediate results), other factors are       typically much more important, such as access path and method, because       they usually have a much bigger impact on performance. As you may know,       physical I/O is orders of magnitude slower than any reading from the       buffer cache, so avoiding I/O has the highest priority in the       optimization strategy. Important cost factors (not necessarily in this       order) are locating and locking a page, the I/O to fetch a (range of)       pages, the cost associated with sorting, hashing and hash joins, etc.       Compared to this any performance difference between selecting all colums       or just a subset of columns from a buffered page is insignificant (if it       is even possible to measure any effect).              --       Gert-Jan              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca