Timeline for Creating a summary table for an averaging query
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 7, 2020 at 22:23 | history | edited | CommunityBot |
added [query-performance] to 2412 questions - Shog9 (Id=1924)
|
|
| Apr 13, 2017 at 12:43 | history | edited | CommunityBot |
replaced http://dba.stackexchange.com/ with https://dba.stackexchange.com/
|
|
| Nov 8, 2016 at 21:39 | answer | added | mendosi | timeline score: 2 | |
| Nov 8, 2016 at 16:28 | comment | added | mineralwasser | @DavidAldridge thanks, good point. I'll implement that. Other than that, do you guys see anything else that could be changed to make things run a little faster? | |
| Nov 8, 2016 at 16:28 | comment | added | mineralwasser | @mendosi precisely yes, due to the different time zones. | |
| Nov 8, 2016 at 8:57 | comment | added | David Aldridge | Maybe not a direct answer, but instead of storing AVG, consider storing both SUM(score) and COUNT(*), giving you total_score and score_count. Those are then aggregatable and an average can then be calculated from them with sum(total_score) / sum(score_count), so you have a more flexible solution that can provide averages at different granularities. | |
| Nov 8, 2016 at 7:17 | comment | added | mendosi | So, if I understand correctly, every member has a different 'yesterday' which prevents you from having a simple date criterion. | |
| Nov 8, 2016 at 6:38 | history | edited | mineralwasser | CC BY-SA 3.0 |
Spelling error
|
| Nov 8, 2016 at 6:32 | history | asked | mineralwasser | CC BY-SA 3.0 |