--=======6C297FEF=======
Content-Type: text/plain; x-avg-checked=avg-ok-43C64EFF; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit
At 12:14 PM 12/17/2004 -0500, Tom Lane wrote:
>Bruno Wolff III <bruno@wolff.to> writes:
> > Greg Stark <gsstark@mit.edu> wrote:
> >> where postgres won't bother with the index since it will be slower
> than just
> >> resorting the entire table.
>
> > Using an index to do an order by is an order N operation. Doing a sort
> > is an order N log N operation. For large values of N, a index will be
> > faster.
>
>Unfortunately not ... the constant factors are such that the index
>solution isn't very competitive at large N, unless the table is already
>well ordered (ie clustered). The sort code is a lot better at avoiding
>random-seeks-all-over-the-disk syndrome.
Which would involve reading less data?
In some cases I'd like to use the method that is more likely to fit within RAM.
Also if there are multiple parallel queries, one could end up with
something similar to random-seeks, so reading/writing less data could still
be better.
Regards,
Link.
--=======6C297FEF=======--
