pasman pasman'ski wrote:
1. Planner will estimate 2 x statistics: time of query with cache empty and with cache filled.
Requires planner to know something about the state of the cache; it doesn't yet. Counting myself there's four people I know who have been tinkering with some aspect of that enough to have written some code related to it. For now the best you can do is lower random_page_cost significantly when you suspect the content you're querying against is cached.
2. Two levels of plannig: standard and long. Long planning may be used when standard optimization generate slow plan, and may use advanced algebraic transformations:
I heard a scholarly treatment of that topic from Jim Nasby recently, where he proposed a boolean GUC to toggle the expanded search behavior to be named plan_the_shit_out_of_it.
The surprisingly difficult part of playing in this area is getting enough public sample data and queries running against them to be able to do such an exercise and have some confidence you didn't decrease performance for the average case in the process.
-- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@xxxxxxxxxxxxxxx www.2ndQuadrant.us -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
