Caching with instance variable is degrading performance - ruby-on-rails

Question

All examples below would have called both pending_notifications? and reviewable_notifications
I have the following set of instance methods for User:
def pending_notifications?
return true if reviewable_notifications.size > 0
end
def reviewable_notifications
#reviewable_notifications ||= self.employee.notifications.where(read: [nil, false])
end
They are used by the view in the following manner:
<% if current_user.pending_notifications? %>
<li><%= link_to fa_icon("envelope") + " #{current_user.reviewable_notifications.count} Notification(s)", user_notifications_path(id: current_user.id) %></li>
<% else %>
<li><%= link_to fa_icon("inbox") + " Notification Center", user_notifications_path(id: current_user.id) %></li>
<% end %>
When I analyze the load, one query is being called:
SELECT COUNT(*) FROM "notifications" WHERE "notifications"."employee_id" = ? AND (("notifications"."read" = 'f' OR "notifications"."read" IS NULL))
This is fine, but before my refactor, I was not using the recommended technique of caching with an instance variable, but I got the exact same query in my analysis. Furthermore, it was consistently running at about 20ms less. Below is how the code was originally written. Why wasn't Rails calling the same query twice? Why is the performance better with the code written this way?
def pending_notifications?
return true if self.employee.notifications.where(read: [nil, false]).size > 0
end
def reviewable_notifications
self.employee.notifications.where(read: [nil, false])
end

Answer 1

Memoizing a value like this is only useful if there's an expensive calculation made in Ruby and you use that value in multiple places.
This particular calculation happens in SQL and Rails already caches DB queries by default, so that's why you didn't see any change.

Answer 2

The difference is not based on the query that is being generated...
It is that if you use
`#reviewable_notifications ||= self.employee.notifications.where(read: [nil, false])`
you will only hit the database as long as #reviewable_notifications is nil.
In the moment it takes a value, it will be used.
As an easy example you can write this in the console:
2.1.2 :001 > 5.times { User.first } # no caching, hit 5 times your DB
User Load (0.2ms) SELECT `users`.* FROM `users` ORDER BY `users`.`id` ASC LIMIT 1
User Load (0.1ms) SELECT `users`.* FROM `users` ORDER BY `users`.`id` ASC LIMIT 1
User Load (0.1ms) SELECT `users`.* FROM `users` ORDER BY `users`.`id` ASC LIMIT 1
User Load (0.1ms) SELECT `users`.* FROM `users` ORDER BY `users`.`id` ASC LIMIT 1
User Load (0.1ms) SELECT `users`.* FROM `users` ORDER BY `users`.`id` ASC LIMIT 1
=> 5
2.1.2 :002 > 5.times { #user ||= User.first } # caching, only 1 hit
User Load (0.1ms) SELECT `users`.* FROM `users` ORDER BY `users`.`id` ASC LIMIT 1
=> 5
Of course, mysql hast its own query cache, so if the same query hits the database, it might be possible that the result is given back from the database query cache (you can see in the example above that the last queries takes less time than the first one, which probably is because mysq serves the results from its cache)