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| %>
…
<%= 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
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 A., 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/.
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.
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.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.