At 12:14 PM 12/17/2004 -0500, Tom Lane wrote:
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> 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.
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
