Den 2012-02-27 12:47 skrev Paulius Pazera såhär:
restore speed is important for big databases. It's a pain to wait 7 hours for
restore to complete (~3 hours for data import and ~4 hours for index
creation). Usually those big databases are already on fastest disk arrays
companies can afford
On 03/11/12 14:48, Kjell Rilbe wrote:
Den 2012-02-27 12:47 skrev Paulius Pazera såhär:
restore speed is important for big databases. It's a pain to wait 7 hours
for restore to complete (~3 hours for data import and ~4 hours for index
creation). Usually those big databases are already on
To: For discussion among Firebird Developers
Subject: Re: [Firebird-devel] gbak improvement
Nick,
When gbak finishes the actual data part of the restore it then creates all
the indexes, could it do that in parallel based on the number of processors
available.
It seems daft that I have to wait for each index
On 23/02/2012 10:50, Nick Upson wrote:
Hi,
before putting this idea into the trackers I wanted to make sure its
not totally crazy.
When gbak finishes the actual data part of the restore it then creates
all the indexes, could it do that in parallel based on the number of
processors
Nick Upson skriver:
Hi,
before putting this idea into the trackers I wanted to make sure its
not totally crazy.
When gbak finishes the actual data part of the restore it then creates
all the indexes, could it do that in parallel based on the number of
processors available.
It seems daft
Nick Upson skriver:
Hi,
before putting this idea into the trackers I wanted to make sure its
not totally crazy.
When gbak finishes the actual data part of the restore it then creates
all the indexes, could it do that in parallel based on the number of
processors available.
It seems daft
Hi,
before putting this idea into the trackers I wanted to make sure its
not totally crazy.
When gbak finishes the actual data part of the restore it then creates
all the indexes, could it do that in parallel based on the number of
processors available.
It seems daft that I have to wait
