From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruno Wolff III <bruno(at)wolff(dot)to> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: sorting problem |
Date: | 2004-12-17 17:14:25 |
Message-ID: | 20873.1103303665@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Bruno Wolff III <bruno(at)wolff(dot)to> writes:
> Greg Stark <gsstark(at)mit(dot)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.
I suppose your argument is good as N goes to infinity, but for
real-world cases we don't seem to reach the asymptotic regime.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-12-17 17:22:52 | Re: Problem with pl/perl in postgresql 8.0rc1 |
Previous Message | Michael Fuhr | 2004-12-17 17:13:47 | Re: Problem with pl/perl in postgresql 8.0rc1 |