X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 40CA0D7FCB for ; Tue, 8 Nov 2005 07:15:27 -0400 (AST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 44321-03 for ; Tue, 8 Nov 2005 11:15:24 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.metronet.co.uk (mail.metronet.co.uk [213.162.97.75]) by svr1.postgresql.org (Postfix) with ESMTP id 830D2D7FC7 for ; Tue, 8 Nov 2005 07:15:24 -0400 (AST) Received: from mainbox.archonet.com (84-51-143-99.archon037.adsl.metronet.co.uk [84.51.143.99]) by smtp.metronet.co.uk (MetroNet Mail) with ESMTP id 5BE90418966; Tue, 8 Nov 2005 11:15:20 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mainbox.archonet.com (Postfix) with ESMTP id 87F0515EDA; Tue, 8 Nov 2005 11:14:44 +0000 (GMT) Received: from mainbox.archonet.com ([127.0.0.1]) by localhost (mainbox [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24004-05; Tue, 8 Nov 2005 11:14:42 +0000 (GMT) Received: from [192.168.1.17] (client17.office.archonet.com [192.168.1.17]) by mainbox.archonet.com (Postfix) with ESMTP id CF29315ED9; Tue, 8 Nov 2005 11:14:41 +0000 (GMT) Message-ID: <437088A1.8090304@archonet.com> Date: Tue, 08 Nov 2005 11:14:41 +0000 From: Richard Huxton User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie Savage Cc: pgsql-performance@postgresql.org Subject: Re: Sort performance on large tables References: <43704E1D.80708@interserv.com> In-Reply-To: <43704E1D.80708@interserv.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.033 required=5 tests=[AWL=0.033] X-Spam-Score: 0.033 X-Spam-Level: X-Archive-Number: 200511/138 X-Sequence-Number: 15395 Charlie Savage wrote: > Hi everyone, > > I have a question about the performance of sort. > Note it takes over 10 times longer to do the sort than the full > sequential scan. > > Should I expect results like this? I realize that the computer is quite > low-end and is very IO bound for this query, but I'm still surprised > that the sort operation takes so long. The sort will be spilling to disk, which will grind your I/O to a halt. > work_mem = 16384 # in Kb Try upping this. You should be able to issue "set work_mem = 100000" before running your query IIRC. That should let PG do its sorting in larger chunks. Also, if your most common access pattern is ordered via tlid look into clustering the table on that. -- Richard Huxton Archonet Ltd