Hello, it seems the problem is related to the VIEW. This is what I also figured out so far. Now I read:
"If you see a *NATURAL *plan going against a big table, you've found the problem. If you have where clause or JOIN to that table, make sure you have index defined on related fields. If you do have index, but it isn't used, perhaps you have ascending index (default) and you need descending (or vice versa). Or perhaps you just need to rebuild the index statistics so that Firebird finds it usable. That can be done with SET STATISTICS sql command. If you use views with unions (you cannot index a view), I highly recommend you use at least Firebird 2.0 as earlier versions don't use any indexes of underlying tables when you use WHERE or JOIN with a view. If you can't use Firebird 2.0, the only way to speed it up is to write a stored procedure that takes value in WHERE clause as agrument." from http://www.firebirdfaq.org/faq13/ I am using firebird 2.1.7 and can confirm that the problematic table has the keyowrd "NATURAL" in the plan analyzer. According to the text indexes should work within views with FB > 2.0. I also added indexes DESC and ASC for any field of the tables which is used in where statements. Any idea how to proceed from here? greetings Matthias On Tue, Mar 3, 2020 at 7:32 AM liviuslivius liviusliv...@poczta.onet.pl [firebird-support] <firebird-support@yahoogroups.com> wrote: > > > Hi > > Without analysis i can only advice to create descending index. > Create descending index ixd_mytable__timestamp on mytable(timestamp) > > Regards, > Karol Bieniaszewski > > >
