On Feb 5, 2008, at 10:28 AM, Michael S. wrote:
Rick, can you be more specific and provide an example, please. To me
intermingled with multiple DB queries. I’m more cautious when it comes
to one to one substitution of Rails-generated SQL with handwritten
I’d expect that in such a case optimization is more a matter of
providing the DBMS with suitable access paths, i.e. indexes, that are
necessary regardless how the SQL of the query is created.
I’m not Rick, but I can give you a couple of concrete examples:
Counter caching can be a huge win. Say every blog page says: This
entry has (3) comments. With counter caching, you can avoid the
database hit each time the post is shown.
By default, Rails does a SELECT *. On a table with many fields, this
can get pretty darn expensive. Instead, for critical queries, use:
@person = Person.find :all, :select => ‘first_name, last_name’
I guess I wouldn’t do this unless you were doing full-table scans of
bulky tables, but I have (in some cases) been able to measure
significant improvements when there was a complex table and all I
needed was a small subset of the information for a given query.
The DataMapper people claim (and I have no reason to doubt this) that
large text or blob fields can be expensive if loaded for each object.
I’m not sure how they do this, but they lazy-load text fields so you
incur the database hit as late as possible (and for the smallest
number of rows required).
Also, AR does query caching. That’s cool, and I suspect it solves many
problems, but it’s a single-machine solution. If you are looking to
offload some of the burden from your primary app server, running a
memcached server on a separate box to cache queries can help.
I’m sure Rick has cooler examples.
This kind of stuff is pretty far in front of the original “worth his
salt” question. I believe one can do a workmanlike job constructing a
Rails app just knowing that some of this stuff can be done, without
ever having done it.
Oh, one other note: textile and markdown are relatively expensive
operations (not SQL related, however), so if you store a preformatted
version of text in your database on create or update, the render will