Timeline for Postgres performance testing, caching and flushing
Current License: CC BY-SA 4.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 29, 2018 at 0:32 | comment | added | Davos | @Hemel "doing the test(s) on the same set of data" will show you improvements for that specific set of parameters, but if your query has a varied range of possible parameters then you are much better off averaging (or something more statistically significant like median or 95th percentile) a range of different parameter sets. You're effectively benchmarking and benchmarks are constructed exactly that way. jjanes has made some good suggestions, including generating a lot of random-realistic scenarios. If you run the same ones, you can't avoid the caching effect. | |
| May 17, 2018 at 11:49 | history | edited | jjanes | CC BY-SA 4.0 |
expand based on comment
|
| May 17, 2018 at 10:03 | comment | added | ConanTheGerbil | the query IS parameterised, but testing against different parameters will give different performance results (some queries will return 1 row, some 10,000) so only by doing the test(s) on the same set of data returning the same set of rows can you really confirm if any performance tweaks have really made a difference. | |
| May 16, 2018 at 20:14 | history | answered | jjanes | CC BY-SA 4.0 |