On Thu, Jul 8, 2010 at 12:24, Konstantin Haase <k.ha...@finn.de> wrote: > > On Jul 8, 2010, at 17:15 , Norman Clarke wrote: > >> On Thu, Jul 8, 2010 at 11:14, Norman Clarke <nor...@njclarke.com> wrote: >> >>> It would be interesting to see the overall performance impact if, for >>> example, the typical "SELECT * FROM table WHERE id = ? LIMIT 1" that >>> AR generates were prepared rather than just executed directly. I would >>> guess that Postgres already has sufficient logic to cache query plans >>> for something like this even without using prepared statements, but >>> I'm not sure. >> >> Ok, I was curious so I took a look into it. >> >> http://gist.github.com/468116 >> >> Unless there's some logical flaw in my benchmark code, it looks like >> prepared statements run about 50% faster overall for these types of >> queries. > > > "Gist has been deleted"
Ah, sorry - let me try again: http://gist.github.com/468126 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
