[firebird-support] Re: Problem with restoring database
Looks like http://tracker.firebirdsql.org/browse/CORE-5228 http://tracker.firebirdsql.org/browse/CORE-5228 Regards, Vlad
[firebird-support] Problem with restoring database
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 records and i suppose it is linked with integer type. When I delete 0,4 bilion records from this database problem disappears. I don’t have a problem with backup this database. Could you please help me? Best regards Krzysztof Chorzępa
Re: [firebird-support] Re: Query optimizer is not using the useful indexes.
Sorry, I tried to say compound index (FECH,HORA).
[firebird-support] Re: Issue with large table in FB 1.5 and 2.5
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 drop all dependencies, then the table, then recreate them all using isql, etc.It works. I ran the result of this through the normal 1 million row load this morning, and it is instant response on SQL queries, etc. This is huge for me & my client. I will monitor this over time, but I definitely would concur with all the posters here in saying that the addition of a TRUNCATE TABLE command would have solved my problem here. I know this is commonly found in other SQL DBMS systems, so it might not only be a feature that really solves real world problems but increases the competitiveness of Firebird with other open source DBMS offerings. Anyway I'm coming to the FB conference in October, so I'd love to buy you all a beer (or your drink of choice) for helping me out. Thanks again. Myles
Re: [firebird-support] Re: Query optimizer is not using the useful indexes.
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.
Re: [firebird-support] Re: How to specify manual plan for this kind of query?
>> 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 when i have added some condition it is changed to PLAN (SORT (JOIN (CTE T T NATURAL, CTE K INDEX (IXA_NAMES_K__NAME))), JOIN (CTE T T NATURAL, CTE K INDEX (IXA_FNAMES_K__ID))) and i need to replace it to oryginal plan Regards, Karol Bieniaszewski
Re: [firebird-support] Re: Query optimizer is not using the useful indexes.
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. ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/firebird-support/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/firebird-support/join (Yahoo! ID required) <*> To change settings via email: firebird-support-dig...@yahoogroups.com firebird-support-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: firebird-support-unsubscr...@yahoogroups.com <*> Your use of Yahoo Groups is subject to: https://info.yahoo.com/legal/us/yahoo/utos/terms/
[firebird-support] Re: Query optimizer is not using the useful indexes.
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')
and "MOVI"."MIEM" = '15JMS45D7A'
and "MOVI"."HECH" = 'N' order
by "PROC")
After testing, I finally found out what is the problem with this query. Before
Firebird 2.5.4, the query optimizer always accepted to use the compound index
MOVI_FECH (FECH,HORA) for optimizing the MOVI part. But since Firebird 2.5.4
and later versions of Firebird, the eninge does not use this index anymore.
That (and ONLY THAT) is making my query to need 24 minutes insted of 1 minute.
I reported the case and my foundings:
http://tracker.firebirdsql.org/browse/CORE-6070
http://tracker.firebirdsql.org/browse/CORE-6070
Thank you.
Re: [firebird-support] Re: Issue with large table in FB 1.5 and 2.5
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 improvement by any newer >>> version, or different server implementation here? >> >> Likely TRUNCATE TABLE ... in Firebird 4.0 comes to rescue here: > > Truncate table (CORE-2479) isn't implemented yet, so it is unsure this > will land in Firebird 4. Oh, right. Thought it is in Firebird 4 Alpha already. Sorry. -- With regards, Thomas Steinmaurer http://www.upscene.com/ Professional Tools and Services for Firebird FB TraceManager, IB LogManager, Database Health Check, Tuning etc.
