> Also one further question Do later versions of Firebird (ie. 3
> or 4) have any performance increase for cooperative garbage
> collection at all?
No. GC requires reading the version chain of all records in the
contexts of their transactions. It takes as long as it takes.
> Would I
Also one further question Do later versions of Firebird (ie. 3 or 4) have
any performance increase for cooperative garbage collection at all? Would I
expect to see any performance improvement by any newer version, or different
server implementation here?
Thanks
Myles
>That is your solution - but *do not delete those records*.
Thank you for the detailed reply, Helen. I can definitely execute a script to
drop all dependencies and then drop the table, and then rebuild them back in
via a CLI Linux script. I thought that was pretty extreme, but if this is the
>To me this sounds like the cooperative garbage collection kicks in when
you select from the table. You may want to consider dropping the table
entirely and recreating it. Alternatively, switch to SuperServer and set
its garbage collection policy to background (I believe this was
introduced in
[..]
> My code that loads the data commits the transactions after the
> DELETE statement, and then at each 5,000 rows loaded. I have
> checked this by watching the load and using IBExpert to count
> records, so I can confirm that the commits are happening.
> After the loading has completed, what
On 29-5-2019 16:19, my...@techsol.org [firebird-support] wrote:
> I am attempting to debug some strange behavior on a large table that
> exhibits the same problems on both FB 1.5 Classic and FB 2.5 Classic.
> This is on a CentOS 7 server, with a ton of RAM and disk, etc.
>
> The database has
>>But this is not the problem, because 2.5.0 does this query very fast, with no
>>special cache settings.Yes, i say the same in the answer ;-)"And about
>>changed plan, it is not releated to this setting but this only increase
>>visibility (of the issue) in your small cache
I am attempting to debug some strange behavior on a large table that exhibits
the same problems on both FB 1.5 Classic and FB 2.5 Classic. This is on a
CentOS 7 server, with a ton of RAM and disk, etc.
The database has about 150 tables in it. One table is the culprit. All other
tables,
29.05.2019 13:37, danysch...@yahoo.com [firebird-support] wrote:
> The very important diference is the plan. 2.5.8 is not using MOVI_FECH
> index, so it must
> read more than one millon records to analize ("MOVI"."FECH" between
> '20190301' and
> '20190412').
Remove "DISTINCT" from
I added this:
http://tracker.firebirdsql.org/browse/CORE-6070
http://tracker.firebirdsql.org/browse/CORE-6070
Thank you.
Hi Karol;
I was investigating what is doing the query optimizer about the MOVI_FECH
index.
I found that using "MOVI.FECH between ...20190301 and 20190412" does not use
MOVI_FECH index.
I also found that if I do "MOVI.FECH >= 20190301 and MOVI.FECH >= 20190412"
does not use
Hi Karol;
But this is not the problem, because 2.5.0 does this query very fast, with no
special cache settings. The very important diference is the plan. 2.5.8 is not
using MOVI_FECH index, so it must read more than one millon records to analize
("MOVI"."FECH" between '20190301' and
>>I enabled in firebird.conf the parameter DefaultDbCachePages = 2048, >>but
>>after that the performace was 1 minute slower.Yes, i am talking about this
>>param you can also set it indyvidually for database. And your value is small.
>>If your db pagesize is 16KB then cache in your case is only
13 matches
Mail list logo
