Enterprise Rails

Other Caching

There are a number of places in an application, both within as well as at the edges, for caching. Each has its own considerations and difficulties. The rest of this chapter provides an overview of these locations, and attempts to point out the most worrisome drawbacks and pitfalls, and what steps may be taken from day one to help get around them. Unfortunately, at some layers there is little recourse when the infrastructure falls short of our hopes. We will start at the bottom and work our way up.

Query Plan Caching

Whenever you execute a database query, the database first must come up with a plan for how to retrieve the data you requested. There may be many ways to go about executing your query, based on the number of tables involved in the query and the number of indexes that may be used.

For large queries, the time spent planning a query generally pales in comparison to the time spent executing the plan. However, any time spent planning queries is time not spent doing something else. And as query complexity rises, so too does the planning time. The number of possible paths to take for N tables joined in a single query is N!, even before you factor in the different ways to treat those tables due to indexes. Finding the very best plan could take an eternity. Because of this, Postgres has a cut-off point for the number of tables after which it will avoid an exhaustive search and instead do a heuristic search for the best query plan so that planning time does not blow ...