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 !