Linq Compiled Queries Q & A

re: Linq Compiled Queries Q&A

Anders Borum — Tue, 26 Aug 2008 01:43:42 GMT

Compiled queries for the win! \o/ :-)

re: Linq Compiled Queries Q&A

Alexander Gornik — Tue, 26 Aug 2008 09:14:07 GMT

Rico, about the linq performance.

Didn't the linq team thought about massive insert / update scenarios?

Our experience shows that you simply can't insert more than several thousand entites (2000-3000) in one datacaontext. Performance in that case seems to fall exponentially (i guess, due to some internal entity graph manipulation). We had to use SqlBulkCopy for that.

And the massive update scenario isn't just supported. Although i can easely imagine something like that:

users.Where(u => u.Role == "Operator").Set(u => u.Status = "Locked")

re: Linq Compiled Queries Q&A

ricom — Tue, 26 Aug 2008 18:22:36 GMT

My impression was that they only went for a core slice of the database operations. It's not everything but it's definately not nothing :)

Now, interestingly, I think anybody could come along and implement the .Set operator you're talking about there. You can use the select statement that everything before the Set would have generated and then look at the expression tree for the mapping function in the .Set, figure out which columns to change then make something like

update foo set <whatever> where foo in (the select statement from before the select)

The hardest part I think is figuring out how you want to express compound updates (many columns into related values).

I'm not a Linq internals expert by any means but I did build a conceptual query engine many years ago (on top of OLEDB) and the above is how our updates worked.

re: Linq Compiled Queries Q&A

Alexander Gornik — Wed, 27 Aug 2008 10:23:44 GMT

Thanks for the reply.

Interesting part about the updates, although it's definitely not that easy to implement with decent quality. :)

And the insert problem is still here.

It's even more sad, that EF doesn't handle this issues too, as it seems to me now.

p.s: where foo in ... can also produce pretty ineffective queries, imho, but at least we can pray for query optimizer here :).

re: Linq Compiled Queries Q&A

ricom — Wed, 27 Aug 2008 20:01:15 GMT

Actually since about SQL2005 "where foo in (...)" has been really about the same plan quality as an inner join (it really is just another way of writing an inner join after all) in all the cases I've had to use it. So that's a good thing :)