Timeline for Postgres 8.3 faster than 9.3?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 3, 2014 at 18:28 | vote | accept | Thomas | ||
| S Jan 28, 2014 at 9:14 | history | suggested | Milen A. Radev | CC BY-SA 3.0 |
Grammar and typos fixed
|
| Jan 28, 2014 at 8:06 | review | Suggested edits | |||
| S Jan 28, 2014 at 9:14 | |||||
| Jan 28, 2014 at 4:08 | comment | added | Pavel Stehule | @AlexKuznetsov - It is effect of higher default_statistics_target. When you increase this value, then you increase time of all manipulation with statistics vectors. For simple queries (where planning and execution is very short) this factor can be detectable (in benchmark like pgbench). In production (less probable) - but it really depends on used queries - but lot of INSERTs without prepared statements can be impacted - but if you use COPY, then all is ok and you never see negative impacts. It is similar like INDEXES - more indexes => maybe faster SELECTs, but surely slower INSERT, UPDATE | |
| Jan 28, 2014 at 1:17 | comment | added | A-K | Pavel, can you elaborate on the following: "Depends on your application (if it use simple or not simple queries)". Did you mean that the simplest queries do not benefit from longer/better planning, but still pay the additional tax for it? | |
| Jan 28, 2014 at 0:00 | comment | added | xenoterracide | +1 just arguing that 8.3 is now unsupported, and thus will receive no updates going forward. | |
| Jan 27, 2014 at 22:35 | history | edited | Pavel Stehule | CC BY-SA 3.0 |
added 109 characters in body
|
| Jan 27, 2014 at 22:27 | history | edited | Pavel Stehule | CC BY-SA 3.0 |
deleted 8 characters in body
|
| Jan 27, 2014 at 22:21 | comment | added | Pavel Stehule | I believe so your numbers strongly depends on used parameters for pgbench. Maybe you hit a physical limits of your hw, and then new software doesn't help. There is lot of factors for new releases - and performance should not be most important: really better monitoring, stronger SQL, and not last - 8.3 is unsupported now. On second hand - maybe these features are not important for you - for some legacy applications - and then you can stay on 8.3. I know so some big companies in car industry did this decision. New releases is important for new application that can use new features. | |
| Jan 27, 2014 at 22:17 | history | edited | Pavel Stehule | CC BY-SA 3.0 |
added 254 characters in body
|
| Jan 27, 2014 at 22:15 | comment | added | Thomas | I'm using pgBench 9.3 against both 8.3 and 9.3 databases. Test is running for about 10 minutes, so it could be longer. I agree real-world testing is better, pgBench is just easier. I was hoping 9.3 would be clearly faster so I could argue better for shipping it sooner. | |
| Jan 27, 2014 at 22:11 | history | answered | Pavel Stehule | CC BY-SA 3.0 |