Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB SQL » View Thread |
Messages 11 to 12 of 12 total |
terribly slow nested inner joins |
Sun, Feb 8 2009 10:33 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Van,
<< The following join condition was applied to the KonceptenNL (B) table: "B"."Syn_K_ID" = "C"."Syn_K_NL_ID" [Row scan (KonceptenNL)] >> This join condition is the problematic one. You need to add the appropriate index to allow this condition to be optimized. Without it, EDB is going to have to visit: (Total Parent Row Visits * 7884 KonceptenNL Rows) * Total Child Rows Obviously, this can get very expensive if the total number of parent and child rows is even 1000. -- Tim Young Elevate Software www.elevatesoft.com |
Sun, Feb 8 2009 10:34 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Van,
<< Adding this index seems to make the difference! Now the execution time is 2.99 seconds; still the double of the BDE, but acceptable. Shouldn't the SQL "engine" know when it should create a temporary index, as apparently the BDE does? If not, please add this hint to your help files!!! >> ElevateDB does not create temporary indexes for SQL execution due to the multi-user issues involved. It is assumed that joins, etc. have the proper indexes defined to make them optimized. -- Tim Young Elevate Software www.elevatesoft.com |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Saturday, May 4, 2024 at 12:54 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |