From: | rihad <rihad(at)mail(dot)ru> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Subject: | Re: Would an index benefit select ... order by? |
Date: | 2007-11-05 06:09:12 |
Message-ID: | 472EB388.6080902@mail.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>> 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Sascha Bohnenkamp | 2007-11-05 11:11:25 | Re: what could be blocking an insertion? |
Previous Message | Kent Tong | 2007-11-05 04:31:35 | what could be blocking an insertion? |