Em 19/4/2012 13:18, Tupy... nambá escreveu: > MSSQL has two commands of the DBCC that allow to do defragmentation. The > defragmentation is not a garbage collection, but putting all parts of an > object (file or columns, hanging of the level - disc or DB) side by side, in > a way that the reading of data will be almost fast, because all data will be > found almost together. Normally,this is the way to have quick readings of > data. Garbage collection is like removing of erased data. > As I quickly read at some PostGreSQL pages, VACUUM has to be a defragment > command for PostGreSQL. > > Since you know that you can make a defragment at Firebird making an DB > restore, you can make a restore and compare the reading times at the two > situations. If you have a meaningfull increase of readings speed (SELECT´s > and so on) after the restore, this will mean that your problem is of high > fragmentation. > Also, after having made the restore, you can do a new backup and once again, > a second restore, and see if you have time reduce. At the first restore, the > time has to be long, but at the second, no more, because the second backup > will store defragmented data. > If you can, let´s try.... till now, all I have are only theories. Your > results will be interesting for all of us. >
I don't said the Garbage Collection is the same as defragmentation on MSSQL, I said that I don't know about PG, but I *think* VACCUMM is the same as FB Garbage Collection :) and I didn't say that I am sure about it All the tests are done on freshly restore DB, so it's not "fragmented", the slowness is on back-up/restore of a freshly created test database. In this moment I am doing tests with Carlos Cantu and Dmitry Kuzmenko, and the culprit so far is my machine, on their machine (both !) the restore took 3s in mine 10 minutes ! I am testing on ext3 and ext4 partitions and I will make more tests on another machine, so I can isolate hardware as a factor. see you !
