"Bupp Phillips" <hello@noname.com> writes:
> but...
>
> select * from customer order by customer_id, first_name;
> QUERY PLAN:
> Sort(cost=142028.25..142028.25 rows=102834 width=724)
> -> Seq Scan on customer (cost=0.00..4617.34 rows=102834 width=724)
> Total runtime: 19999.81 msec
Actually in this case the optimizer would likely still use a sequential scan
even if it had an index it thought it could use. If you're going to be reading
the whole table anyways it'll be faster to read it in order than to jump all
around even if you have to sort it.
However you do have a point. In this case I don't think postgres even
considers using the index. Even if it would decide not to use it in this case
there could conceivably be cases where it would want to use it.
However I'm not sure I see a lot of cases where this would come up. Even in
automatically generated code, which is the usual cause of redundant things
like this, I don't think I've seen this particular combination ever come up.
--
greg