Comments on: Indexing LINQ http://blog.lab49.com/archives/1031 Technology and industry insights from Lab49. Sat, 24 Sep 2011 08:33:50 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Damien Morton http://blog.lab49.com/archives/1031/comment-page-1#comment-58590 Damien Morton Thu, 31 May 2007 22:50:05 +0000 http://blog.lab49.com/?p=1031#comment-58590 Hi Matt, Are the indexes are rebuilt each time the query is executed? Hi Matt,

Are the indexes are rebuilt each time the query is executed?

]]> By: Matt Warren http://blog.lab49.com/archives/1031/comment-page-1#comment-58492 Matt Warren Thu, 31 May 2007 15:40:20 +0000 http://blog.lab49.com/?p=1031#comment-58492 Actually the 'join' syntax was designed explicitly not to convert into nested loops. You can do that if you want by using multiple 'from' clauses. However, the 'join' syntax actually maps to the Join() query operator that builds an index over the second sequence and uses the first sequence to probe into the index. Which is a whole lot faster than nested loops in most cases. Actually the ‘join’ syntax was designed explicitly not to convert into nested loops. You can do that if you want by using multiple ‘from’ clauses. However, the ‘join’ syntax actually maps to the Join() query operator that builds an index over the second sequence and uses the first sequence to probe into the index. Which is a whole lot faster than nested loops in most cases.

]]> By: Kalani Thielen http://blog.lab49.com/archives/1031/comment-page-1#comment-57191 Kalani Thielen Sun, 27 May 2007 17:22:33 +0000 http://blog.lab49.com/?p=1031#comment-57191 They can probably deal with this in a straightforward way by passing the restriction (with values substituted from the outer relation) to the inner relation for each record in the outer relation. The 'back-end' can possibly provide a more efficient iterator; otherwise you'd fall back to searching the cartesian-product. You wouldn't get most-efficient ordering that way (if the inner relation is smaller than the outer relation, it'd be better to quantify on the inner one), but you'd at least optimally have O(n log m) time, rather than O(n m). And it would still look like a nested loop, which reasonably explains what it's really doing in a join. They can probably deal with this in a straightforward way by passing the restriction (with values substituted from the outer relation) to the inner relation for each record in the outer relation. The ‘back-end’ can possibly provide a more efficient iterator; otherwise you’d fall back to searching the cartesian-product.

You wouldn’t get most-efficient ordering that way (if the inner relation is smaller than the outer relation, it’d be better to quantify on the inner one), but you’d at least optimally have O(n log m) time, rather than O(n m).

And it would still look like a nested loop, which reasonably explains what it’s really doing in a join.

]]>