Timeline for Why is the candidate composite index not used?
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 24, 2020 at 14:33 | comment | added | Rick James |
@sbrattla - Valid question; but there is no problem. SUM() and + are performed in BIGINT (or DOUBLE), then stored into the size of the target column. (- and UNSIGNED sometimes cause some hiccups.)
|
|
| Jun 24, 2020 at 8:33 | comment | added | sbrattla | Thanks @Rick James, yes, there's actually no reason to use INT(10) . The max value in any of these fields is in the thousands, so a SMALLINT should do. I assume the "to be" column data type (SMALLINT) will not then prevent me from doing a SUM over the field? That is, the data type of the SUM'ed fields will not be limited to the size of SMALLINT? | |
| Jun 24, 2020 at 6:25 | comment | added | Rick James |
@sbrattla - Yes, storing as Binary helps. For a tiny bonus, consider changing other columns from a 4-byte INT to some smaller numeric type.
|
|
| Jun 24, 2020 at 6:22 | comment | added | sbrattla | Thanks @Rick James. I will try to redo the index. I know UUIDs are inefficient, but that's just how it is. I can't fix that. However, that is why I've been trying to compact the tables a little by storing the UUIDs as binary. | |
| Jun 24, 2020 at 6:05 | history | answered | Rick James | CC BY-SA 4.0 |