Jesper Krogh <jesper@xxxxxxxx> writes: > testdb=# set seq_page_cost = 0.00001; > SET > testdb=# set random_page_cost = 0.00001; > SET Well, hmm, I really doubt that that represents reality either. A page access is by no means "free" even when the page is already in cache. I don't recall anyone suggesting that you set these numbers to less than perhaps 0.01. In the case at hand, the problem is that the planner is preferring using an indexscan to an after-the-fact sort to obtain the specified result ordering. Making page fetches look too cheap definitely plays into that. There may also be a statistical problem, if the location of the desired records isn't independent of the accession_number ordering, but you're not doing yourself any favors by pushing the planner cost parameters several orders of magnitude outside the design envelope. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
