Comments on: Creating a counter_cache column

By: Jerrett

Jerrett — Wed, 05 Aug 2009 21:41:27 +0000

“I think most people wouldn’t know how to start by creating temp tables and pushing/pulling the data via a migration.”

… And these people are writing code?

By: Andy Watts

Andy Watts — Thu, 04 Jun 2009 16:33:23 +0000

Thanks for this.
Totally agree, doing this through AR gets slow quickly.

By: daniel

daniel — Tue, 26 May 2009 16:06:37 +0000

Excellent! Used it for a table with about 500000 entries, an it just took a minute. Instead of apprx. 2 hours, which is the time required to iterate over the objects. Thanks!

By: jfromm

jfromm — Tue, 16 Dec 2008 09:45:26 +0000

Yes, it is not only a reasonable way to speed up code, it is also useful to sort items. I wrote about it here

By: Chip Ramsey

Chip Ramsey — Wed, 22 Oct 2008 17:51:16 +0000

Same concept for PostgresSQL:

UPDATE accounts
SET users_count = comm.the_count
FROM (select account_id, count(*) as the_count from users where is_active = ‘t’ group by account_id) as comm
WHERE accounts.id = comm.account_id;

By: Erik Andersson

Erik Andersson — Sun, 17 Feb 2008 21:12:23 +0000

This was exactly what i needed! Thank you!

By: Josh Owens

Josh Owens — Tue, 22 Jan 2008 06:32:05 +0000

Mike,

I see your point, but I would worry about people who *haven’t* implemented a counter cache and have 2 million objects that are associated. I think the speed up a counter cache provides will be found much sooner than 2 million objects.

I think most people wouldn’t know how to start by creating temp tables and pushing/pulling the data via a migration.
Just my $0.02

By: mperham

mperham — Fri, 28 Dec 2007 18:46:10 +0000

Josh, please read my blog posting over again. You are doing exactly what I said: iterating through each Recipe one at a time and initializing its counter value. If you have 2,000,000 recipes, this will require 2,000,000 queries and a lot of memory (since you will be holding 2m recipes in memory after the find(:all)). The query I give above will do all that work in a single query with no memory overhead (all the hard work is pushed to the database layer).

By: Josh Owens

Josh Owens — Fri, 28 Dec 2007 17:51:42 +0000

Why use MySQL directly? Just use migrations…

http://josh.the-owens.com/archives/2007/11/03/rails-edge-change-how-to-add-a-counter-cache-to-an-existing-db-table/