* Jeroen van Rijn <jvr...@gmail.com> [2013-04-04 21:54:46]: > On Thu, Apr 4, 2013 at 9:35 PM, David MENTRÉ <dmen...@linux-france.org>wrote: > > > Hello Maxime, > > > > Le 04/04/2013 20:45, Maxime Petazzoni a écrit : > > > > Isn't postgresql vacuum process supposed to do that? Do we need a > >>> >cleanup process at application level? > >>> > >> Vacuum takes an exclusive lock on the database and takes (interestingly) > >> longer than doing a full planet import. > >> > > > > Yes, that's strange! Those database issues are out of my knowledge but I > > nonetheless think this vacuum behaviour should not occur. > > > At the very least I think it's an interesting test case to bring the > Postres/PostGIS guys in on, we might have stumbled onto an edge case in > vacuum performance.
Not really, it's just the way vacuum works, and on a database that big it takes a very long time, which we can't afford. > I was also thinking along these lines. If the growth is because of the lack > of vacuuming and the vacuuming takes this long because it's never been done > after the initial import (I know full import disables it), it may very well > be that suspending renders and minutely updates every hour and triggering a > vacuum, it'll bring the database size down in minutes flat. The main issue is that we do have vacuum turned off otherwise upgrades were too slow. Now that we have SSDs though, I can try turning it back on after the full import and see if that helps. I've started a new import today, I'll let you know how it goes. /Max -- Maxime Petazzoni <http://www.bulix.org> ``One by one, the penguins took away my sanity.'' Writing software in California
signature.asc
Description: Digital signature
