>> 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.
