Forum: Ruby on Rails sql performance

Hi all.
I have a sql performance problem. Would be great to get some 
inspiration.

model hour: id, week_id, :user_id, project_id, hour

controller:
@hours = Hour.project(@project.id)

update:
if params[:booking_user_ids]
      params[:booking_user_ids].each do
        Hour.update(params[:booking_user].keys,
params[:booking_user].values).reject { |p| p.errors.empty? }
      end
    end


view:
<% @hours.group_by(&:user_id).sort.each do |user, hours| %>
....

<%= simple_form_for @hour, :url => hour_path, :remote => true,  :method 
=>
:put do %>
<%= render 'form_user', :hours => hours %>

partial:
<% hours.each do |week|%>

    <%= fields_for "booking_user[]", week do |w| %>
    <%= w.text_field :hour, :class => 'submittable' %>
    <%= hidden_field_tag "booking_user_ids[]", w %>

Form entries are stored but on reload it gives me tons of:
  CACHE (0.0ms)  SELECT `hours`.* FROM `hours` WHERE `hours`.`id` = 189
LIMIT 1
   (1.0ms)  BEGIN
   (0.9ms)  COMMIT
and takes 11 seconds


on the second reload is fine 300 milsec.
Any idea to improve that?
Thanks

On Tue, Jan 15, 2013 at 5:25 AM, Werner 
<webagentur.laude@googlemail.com> wrote:

> Form entries are stored but on reload it gives me tons of:
>   CACHE (0.0ms)  SELECT `hours`.* FROM `hours` WHERE `hours`.`id` = 189
> LIMIT 1

That sounds like you could benefit from a .includes on your initial
load.  Google "N + 1 queries problem".

-Dave

--
Dave Aronson, the T. Rex of Codosaurus LLC,
secret-cleared freelance software developer
taking contracts in or near NoVa or remote.
See information at http://www.Codosaur.us/.

On 01/16/2013 02:04 PM, Dave Aronson wrote:
> On Tue, Jan 15, 2013 at 5:25 AM, Werner <webagentur.laude@googlemail.com> wrote:
>
>> Form entries are stored but on reload it gives me tons of:
>>    CACHE (0.0ms)  SELECT `hours`.* FROM `hours` WHERE `hours`.`id` = 189
>> LIMIT 1
> That sounds like you could benefit from a .includes on your initial
> load.  Google "N + 1 queries problem".
>
> -Dave
>
I don't think so.  The CACHE entries mean that the op did the same fetch
as he had recently done and the data was still around and was used with
no db access.

Norm

On Wed, Jan 16, 2013 at 5:22 PM, Norm Scherer 
<normscherer@earthlink.net> wrote:
>> load.  Google "N + 1 queries problem".
>>
>> -Dave
>>
> I don't think so.  The CACHE entries mean that the op did the same fetch as
> he had recently done and the data was still around and was used with no db
> access.

Should also note that the cache only hangs around as long as the request 
does.