You mean Postgres wouldn't *always* use created_at's index with such
access patterns on a big table (even if one exists):
select * from foo order by created_at desc;
No, it wouldn't necessarily, and that's a good thing. A full-table
indexscan can often be slower than a sort because of inefficient disk
access patterns. The planner will estimate the cost of each possibility
and pick the one that looks cheaper.
What if it's really a limited select:
select * from foo order by created_at desc limit <SCREEN_AT_A_TIME>;
because this is what I meant initially (sorry), would Postgres always
use index to get at sorted created_at values, so I don't *have* to
create the index? I think maintaining the index has its own penalty so
in my upcoming project I'm evaluating the option of skipping defining
one entirely unless absolutely necessary.
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
