Timeline for Why is a COUNT query faster than a result set query?
Current License: CC BY-SA 4.0
3 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 14, 2019 at 13:41 | comment | added | Lennart - Slava Ukraini | Not necessarily, there's probably an index that covers the join predicate but do not necessarily cover other referenced columns. Therefore in the case of the count it is sufficient to traverse the index(es), whereas additional fetch of data has to be done in the other case (like @david-spillett demonstrates in his answer) | |
| Feb 14, 2019 at 12:29 | comment | added | joedotnot | Given that the WHERE clause with JOINS etc.. are the same in both cases.. If there is to be table-scanning it should happen with both queries; if there is to be primary key scanning it would happen in both cases. Hence my reasoning that, at least for this part of the work to determine who qualifies to be included in the result set, it would take similar effort. Then of course, preparing the columns to return is another chunk of work done by the DB-engine, which in the case of count is not required. Or am I totally wrong in thinking this way? | |
| Feb 14, 2019 at 9:44 | history | answered | Lennart - Slava Ukraini | CC BY-SA 4.0 |