sql performance

[Werner]

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

[Dave Aronson]

On Tue, Jan 15, 2013 at 5:25 AM, Werner <webagent...@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/.

[Norm Scherer]

On 01/16/2013 02:04 PM, Dave Aronson wrote:
> On Tue, Jan 15, 2013 at 5:25 AM, Werner <webagent...@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

[Jordon Bedwell]

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