Thanks to Luke and Tom for the input. I guess this was good timing
given that it looks like
8.2 was just released today. I will upgade to that before doing
anything else.
Glenn
Tom Lane wrote:
Glenn Sullivan <[EMAIL PROTECTED]> writes:
I am wanting some ideas about improving t
Steinar H. Gunderson wrote:
> On Tue, Dec 05, 2006 at 01:02:06PM -0500, Tom Lane wrote:
>> In 8.0 that might be counterproductively high --- we have seen cases
>> where more sort_mem = slower with the older sorting code. I concur
>> with Luke's advice that you should update to 8.2 (not 8.1) to get
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes:
> By the way, is the new sorting code any better for platforms that already
> have a decent qsort() (like Linux)?
It seemed better to us. Linux' qsort() is really mergesort, which is
better sometimes but often worse --- mergesort tends to have a
am Tue, dem 05.12.2006, um 13:02:06 -0500 mailte Tom Lane folgendes:
> In 8.0 that might be counterproductively high --- we have seen cases
> where more sort_mem = slower with the older sorting code. I concur
> with Luke's advice that you should update to 8.2 (not 8.1) to get the
> improved sorti
On Tue, Dec 05, 2006 at 01:02:06PM -0500, Tom Lane wrote:
> In 8.0 that might be counterproductively high --- we have seen cases
> where more sort_mem = slower with the older sorting code. I concur
> with Luke's advice that you should update to 8.2 (not 8.1) to get the
> improved sorting code.
By
Glenn Sullivan <[EMAIL PROTECTED]> writes:
> I am wanting some ideas about improving the performance of ORDER BY in
> our use. I have a DB on the order of 500,000 rows and 50 columns.
> The results are always sorted with ORDER BY. Sometimes, the users end up
> with a search that matches most of t
Glenn,
On 12/5/06 9:12 AM, "Glenn Sullivan" <[EMAIL PROTECTED]> wrote:
> I am wanting some ideas about improving the performance of ORDER BY in
> our use. I have a DB on the order of 500,000 rows and 50 columns.
> The results are always sorted with ORDER BY. Sometimes, the users end up
> with a
I am wanting some ideas about improving the performance of ORDER BY in
our use. I have a DB on the order of 500,000 rows and 50 columns.
The results are always sorted with ORDER BY. Sometimes, the users end up
with a search that matches most of the rows. In that case, I have a
LIMIT 5000 to kee
