> My guess is that the rows you're added reduces the selectivity of
> SL_CSDTL_ITEMCODE and that this makes Firebird (incorrectly) believe that
> the bad plan becomes better than the good plan. You can prevent Firebird
> from using the bad plan by changing the query a bit (I've also changed it to
>Query:
>
>SELECT MAX(A.PostDate) MaxPostDate
>FROM SL_CS A, SL_CSDTL B
>WHERE A.DocKey=B.DocKey
> AND A.Code='300-10001'
> AND B.ItemCode='OCC'
> AND B.UOM='UNIT'
> AND A.Cancelled='F'
> AND B.UnitPrice<>0
>
>Good plan:
>PLAN JOIN (B INDEX (SL_CSDTL_ITEMCODE), A INDEX (RDB$PRIMAR
It is strange why the firebird choose wtong plan when database file size grow
beyond 8GB. I thought it should be consistent for same query.
Hi,
There should a reason why optimizer chooses the wrong plan.
Try to recalculate indices statistics.
Also, for general performance, use optimized Firebird configuration:
http://ib-aid.com/en/optimized-firebird-configuration/
Regards,
Alexey Kovyazin
IBSurgeon HQbird
www.ib-aid.com
I am using
I am using Firebird 2.5.5 x64 on Windows 8.1 x64. I wrote an application
access a Firebird database. So far so good.
One day, I notice a function running query accessing the database become
extremely slow. After I debug, I found the query is the cause:
SELECT MAX(A.PostDate) MaxPostDat