Ogden <lists@xxxxxxxxxxxxxx> wrote: > In conclusion, I should keep my random_page_cost (3.0) to a value > more than seq_page_cost (1.0)? Is this bad practice or will this > suffice for my setup (where the database is much bigger than the > RAM in the system)? The idea is to adjust the costing factors to model the actual relative costs of the various actions in your environment with your workload. The best way to determine whether your settings are good is to gauge how happy the those using the database are with performance. :-) The degree of caching has a large effect on the page costs. We've managed to keep the active portion of our databases cached to a degree that we have always benefited by reducing the random_page_cost to 2 or less. Where the entire database is cached, we get the best plans with seq_page_cost and random_page_cost set to equal values in the 0.1 to 0.05 range. We've occasionally needed to bump the cpu_tuple_cost up a bit relative to other cpu costs, too. On the other hand, I've seen reports of people who have found it necessary to increase random_page_cost to get good plans. These have been people with large databases where the entire database is "active" (versus our databases where recent, active data is accessed much more heavily than, say, 20 year old data). If you model the costing to reflect the reality on your server, good plans will be chosen. -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
