Looks like http://tracker.firebirdsql.org/browse/CORE-5228
http://tracker.firebirdsql.org/browse/CORE-5228
Regards,
Vlad
Hi
I have a problem with restoring the database. I use gbak.exe on firebird
2.5.8. Proces of restoring the database stops during the restoration of
records – logs and file doesn't grows, processor is loaded on 100%, but I
don’t have any errors. My problem started when database exceeded 4,4
billion
Sorry, I tried to say compound index (FECH,HORA).
An update and a huge thank you to everyone for your input and help on this. I
spent most of yesterday writing Linux bash scripts and closing off ports on the
database server so I could run this from a remote SSH request from a web
server. I wrote a pretty extensive script library that will dro
What I uderstand is, simply by adding a new index for the field FECH, makes
this query to go faster again, like it was before Firebird 2.5.4 in where
something changed, making it does not use my compound index (FECH,MOVI) anymore.
>> Really? I'd suppose the changed part should be:
>> HASH (CTE T T NATURAL, CTE K NATURAL))
>> Dmitry
No,
My oryginal plan generated by Firebird looks like this
PLAN (SORT (JOIN (CTE T T NATURAL, CTE K INDEX (IXA_NAMES_K__NAME))), HASH (CTE
T T NATURAL, CTE K INDEX (IXA_FNAMES_K__ID)))
and
31.05.2019 13:18, danysch...@yahoo.com [firebird-support] wrote:
> That (and ONLY THAT) is making my query to need 24 minutes insted of 1 minute.
Do you understand that DISTINCT inside of IN is meaningless?
--
WBR, SD.
--
Hello;
select “PROC” from “PROC” where “PROC” in (
select distinct "PROC"
from "MOVI"
where "MOVI"."TIPO" in ('1','A','B')
and ("MOVI"."FECH" between
'20190301' and '20190412')
Hi Mark,
> On 30-5-2019 16:14, Thomas Steinmaurer t...@iblogmanager.com
> [firebird-support] wrote:
>>> 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
