|Subject||Re: [firebird-support] Re: Issue with large table in FB 1.5 and 2.5|
> Also one further question.... Do later versions of Firebird (ie. 3No. GC requires reading the version chain of all records in the
> or 4) have any performance increase for cooperative garbage
> collection at all?
contexts of their transactions. It takes as long as it takes.
> Would I expect to see any performance improvement by any newerNo.
> or different server implementation here?Possibly...with Superserver you can can configure for GC to run in
background; or as a combination of background and co-op. Its
performance would have to be tested with your machine's resources,
otherwise it's just one of those "How long is a piece of string?"
One idea that might give you some time saving (again, testing with
actual data is the only way you're going to find out) is to define
your table as a GTT with the same metadata as the one you are
currently using and the ON COMMIT PRESERVE ROWS property. Remove the
dependencies from the current table and just use it for data collection.
Before you run your stored procs, feed the data from the collection
table into the GTT and have the SPs read from that instead. Deleting
records and dropping the GTT is not in the picture, as the data in the
GTT will simply disappear when the connection detaches. Then you can
just drop and recreate the collection table at will without affecting
Of course, if you are still using Fb 1.5 for some sites, it's not
going to work for them. GTTs didn't come on the scene till 2.1. Also,
it won't work in 2.1 +, either, if you have not upgraded the ODS of
the databases to 11.1 or higher.
This email has been checked for viruses by AVG.