On Wed, Mar 29, 2006 at 07:19:10PM +0200, Rafael Martinez wrote: > On Tue, 2006-03-28 at 17:17 -0600, Jim C. Nasby wrote: > > On Wed, Mar 29, 2006 at 01:05:59AM +0200, Rafael Martinez wrote: > > > I work with postgresql every day and I am very happy with it, but this > > > does not mean I can not see the issues that could be improve to have a > > > even better open source DBMS. And I think in my humble opinion that > > > bloated indexes + better upgrade procedures between major releases are > > > two things that should get improved in the future. > > > > FWIW, I don't know of any upgrade procedures for databases that can > > quickly do an in-place upgrade when underlying file structures change, > > because ultimately you need to read and write the entire database > > on-disk. > > I know there is not an easy solution to the dump/restore procedure, and > maybe even it is not possible (I am not a postgres developer and don't > know the postgres internals and what it is necessary to do between major > releases) Does the file structures change always between every major > release? It depends. Sometimes the changes aren't as much in the files as they are in the system catalogs. Ideally, what we'd have is the ability to deal with data that was stored in the last versions format. Any time an old row gets changed, it gets re-written in the new format (probably on a different page). While this would present some challenges, it would make for very, very fast upgrades. Unfortunately, it would also greatly increase code complexity and maintenance costs, so it's rather unlikely it will ever happen. Maybe if someone forks over a very large sum of money, but even then it's unlikely... An actual upgrade script is more likely, but even there you still need to have a backup (actually, that's really pretty true of both cases). This idea does have some traction though, and if someone produced a working utility there's a decent chance it would be accepted. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@xxxxxxxxxxxxx Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
