On 03/16/2011 12:44 PM, Kevin Grittner wrote:
Well, that's one way of looking at it. Another would be that the slower plan with the backward scan was only estimated to be 14.5% less expensive than the fast plan, so a pretty moderate modifier would have avoided this particular problem.
I was wondering about that myself. Considering any backwards scan would necessarily be 10-100x slower than a forward scan unless the data was on an SSD, I assumed the planner was already using a multiplier to discourage its use.
If not, it seems like a valid configurable. We set our random_page_cost to 1.5 once the DB was backed by NVRAM. I could see that somehow influencing precedence of a backwards index scan. But even then, SSDs and their ilk react more like RAM than even a large RAID... so should there be a setting that passes such useful info to the planner?
Maybe a good attribute to associate with the tablespace, if nothing else. -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604 312-676-8870 sthomas@xxxxxxxxx ______________________________________________ See http://www.peak6.com/email_disclaimer.php for terms and conditions related to this email -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
