Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 37514B5DBB6 for ; Mon, 23 May 2011 14:57:12 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 60356-06 for ; Mon, 23 May 2011 17:57:05 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.gransy.com (mail.gransy.com [82.208.29.194]) by mail.postgresql.org (Postfix) with ESMTP id 5844EB5D8BD for ; Mon, 23 May 2011 14:57:05 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by mail.gransy.com (Postfix) with ESMTP id 163534A223E for ; Mon, 23 May 2011 19:57:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at nathalia.gransy.com Received: from mail.gransy.com ([127.0.0.1]) by localhost (Nathalka.gransy.com.gransy.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhOTZtZXC5C1 for ; Mon, 23 May 2011 19:57:03 +0200 (CEST) Received: from [192.168.1.221] (ip-94-112-0-189.net.upcbroadband.cz [94.112.0.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.gransy.com (Postfix) with ESMTPSA id 689F04A221C for ; Mon, 23 May 2011 19:56:58 +0200 (CEST) Message-ID: <4DDA9FEB.7020001@fuzzy.cz> Date: Mon, 23 May 2011 19:56:59 +0200 From: Tomas Vondra User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101219 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: SORT performance - slow? References: <4DD9982C.6000807@fuzzy.cz> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201105/305 X-Sequence-Number: 43814 Dne 23.5.2011 19:01, Maciek Sakrejda napsal(a): >> You're probably reading it wrong. The sort itself takes about 1 ms (just >> subtract the numbers in "actual="). > > I thought it was cost=startup_cost..total_cost. That is not quite the > same thing, since startup_cost is effectively "cost to produce first > row", and Sort can't really operate in a "streaming" fashion (well, > theoretically, something like selection sort could, but that's beside > the point) so it needs to do all the work up front. I'm no explain > expert, so someone please correct me if I'm wrong. Good point, thanks. In that case the second number (2.3 sec) is correct. I still think the problem is not the sorting but the inaccurate estimates - fixing this might yield a much better / faster plan. But the OP posted just a small part of the plan, so it's hard to guess. regards Tomas