[Lift] Re: PreCache's use of WHERE ... IN
David Pollak feeder.of.the.be...@gmail.com writes: On Tue, Aug 18, 2009 at 3:24 PM, harryh har...@gmail.com wrote: Because making things line up name-wise for joins (especially when you're joining to the same table) is a lot more difficult. All RDBMS except MySQL will optimize both inner queries and joins the same way. Interesting. I have been considering switching to PostgreSQL (for reasons unrelated to this), and this issue may speed up my move. What RDBMS are others generally using with Lift? Are there any general recommendations? I use PostgreSQL for all my production sites. It's amazingly solid. +1 /Jeppe --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: PreCache's use of WHERE ... IN
And PostGIS rocks if you do any GIS-related stuff. On Tue, Aug 18, 2009 at 5:25 PM, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Aug 18, 2009 at 3:24 PM, harryh har...@gmail.com wrote: Because making things line up name-wise for joins (especially when you're joining to the same table) is a lot more difficult. All RDBMS except MySQL will optimize both inner queries and joins the same way. Interesting. I have been considering switching to PostgreSQL (for reasons unrelated to this), and this issue may speed up my move. What RDBMS are others generally using with Lift? Are there any general recommendations? I use PostgreSQL for all my production sites. It's amazingly solid. -harryh -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: PreCache's use of WHERE ... IN
And PostGIS rocks if you do any GIS-related stuff. Which I am (this was my other reason for planning on migrating over). I guess it's time to take the plunge. -harryh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: PreCache's use of WHERE ... IN
Because making things line up name-wise for joins (especially when you're joining to the same table) is a lot more difficult. All RDBMS except MySQL will optimize both inner queries and joins the same way. Interesting. I have been considering switching to PostgreSQL (for reasons unrelated to this), and this issue may speed up my move. What RDBMS are others generally using with Lift? Are there any general recommendations? -harryh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: PreCache's use of WHERE ... IN
On Tue, Aug 18, 2009 at 1:51 PM, harryh har...@gmail.com wrote: Given something like Tip.findAll(By(Tip.venueid, ), PreCache (Tip.userid)) The PreCache query param appears to do it's preaching by generating a query that uses IN, like so: SELECT DISTINCT users.id, users.firstname, users.lastname FROM users WHERE id IN (SELECT userid FROM tips WHERE venueid = ); This is a bit concerting as I have found queries of this form to be far less efficient (on a stock MySQL instance at least) than something like this (which will return the same results): SELECT DISTINCT users.id, users.firstname, users.lastname FROM users, tips WHERE tips.userid = users.id AND tips.venueid = ; Is there any particular reason that Lift is generating WHERE ... IN queries? Because making things line up name-wise for joins (especially when you're joining to the same table) is a lot more difficult. All RDBMS except MySQL will optimize both inner queries and joins the same way. Is there some way to instruct Lift to do otherwise? No. If not, should this possibly be changed? It's not a high priority for me, but maybe on of the other committers wants to take up the project. This is somewhat related to my last post on this thread as it also relates to WHERE ... IN queries. http://groups.google.com/group/liftweb/browse_thread/thread/14d4a5aac48ac73d/ -harryh -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
