network profile
| bio | website | users.cs.cf.ac.uk/… |
|---|---|---|
| location | Cardiff, United Kingdom | |
| age | 30 | |
| visits | member for | 7 months |
| seen | yesterday | |
| stats | profile views | 2 |
I love programming. I am interested in new technologies, applications and solutions.
I am contributing to open source projects, e.g. DANS DBF Library for Java, RePast agent-based modelling and simulation platform.
Big Fan of Java.
|
Mar 25 |
revised |
PostgreSQL performance degradation over time on a write intensive db deleted 5 characters in body |
|
Oct 30 |
awarded | Scholar |
|
Oct 30 |
accepted | PostgreSQL performance degradation over time on a write intensive db |
|
Oct 25 |
awarded | Teacher |
|
Oct 25 |
revised |
PostgreSQL performance degradation over time on a write intensive db added 157 characters in body |
|
Oct 25 |
revised |
PostgreSQL performance degradation over time on a write intensive db deleted 21 characters in body |
|
Oct 25 |
revised |
PostgreSQL performance degradation over time on a write intensive db deleted 21 characters in body |
|
Oct 25 |
awarded | Supporter |
|
Oct 25 |
answered | PostgreSQL performance degradation over time on a write intensive db |
|
Oct 25 |
revised |
PostgreSQL performance degradation over time on a write intensive db edited tags |
|
Oct 25 |
comment |
PostgreSQL performance degradation over time on a write intensive db The problem is that Select and Update take longer and longer just as if they were not commited? and the vacuuming doesn't help. |
|
Oct 25 |
revised |
PostgreSQL performance degradation over time on a write intensive db added 72 characters in body |
|
Oct 24 |
revised |
PostgreSQL performance degradation over time on a write intensive db added 593 characters in body |
|
Oct 24 |
awarded | Student |
|
Oct 24 |
comment |
PostgreSQL performance degradation over time on a write intensive db @dezso I think I found that the problem also is present on the development machine apparently my recent optimization of the config for insert timing had an impact on updates/selects? Please see UPDATE2. |
|
Oct 24 |
comment |
PostgreSQL performance degradation over time on a write intensive db Colin, @FrankHeikens and dezso please see UPDATE2 for explain results. Maybe you have some suggestions as to what could be done here to stabilise the update/select time? |
|
Oct 24 |
revised |
PostgreSQL performance degradation over time on a write intensive db Added Update2 related to update/select taking a lot. |
|
Oct 24 |
comment |
PostgreSQL performance degradation over time on a write intensive db Yea I am working on that at the moment. I am restoring the data as we speak but from what I see it could take a long while. But on Win though the largest table had 70m rows and was growing for about 5m a day it handled it with constant 3.5ms. Will get EXPLAINs to you guys as soon as I can, i.e. the restore is completed. Thanks for you involvement. |
|
Oct 24 |
comment |
PostgreSQL performance degradation over time on a write intensive db Yea in all there were no keys. I know that there should be keys present in the first place. Though someone entered the data structure manually rather than from a dump thus forgetting to get the keys. But the indexes were still present. Thus I was wondering if the lack of any sort of keys would in fact impact it if each single query (select/insert/update) are executed on a single table, thus any relation between tables simply is not present in the used queries? |
|
Oct 24 |
revised |
PostgreSQL performance degradation over time on a write intensive db added 54 characters in body |
