Received: from localhost (pluto.hub.org [200.46.204.4]) by postgresql.org (Postfix) with ESMTP id A3EC99F9DAD for ; Wed, 22 Nov 2006 09:51:37 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.4]) (amavisd-new, port 10024) with ESMTP id 20442-04 for ; Wed, 22 Nov 2006 09:51:19 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id 0B3689FA456 for ; Wed, 22 Nov 2006 09:51:26 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.3 Received: from mail.logix-tt.com (mail.logix-tt.com [212.211.145.186]) by svr4.postgresql.org (Postfix) with ESMTP id 131625AFCE7 for ; Wed, 22 Nov 2006 10:17:31 +0000 (GMT) Received: from kingfisher.intern.logix-tt.com (p549D17F7.dip0.t-ipconnect.de [84.157.23.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.logix-tt.com (Postfix) with ESMTP id C83FF64B84 for ; Wed, 22 Nov 2006 11:20:11 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by kingfisher.intern.logix-tt.com (Postfix) with ESMTP id D96581866239A for ; Wed, 22 Nov 2006 11:17:23 +0100 (CET) Message-ID: <456423B3.7010505@logix-tt.com> Date: Wed, 22 Nov 2006 11:17:23 +0100 From: Markus Schaber Organization: Logical Tracking and Tracing International AG, Switzerland User-Agent: Thunderbird 1.5.0.7 (X11/20060927) MIME-Version: 1.0 To: PostgreSQL Performance List Subject: PostgreSQL underestimates sorting X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200611/183 X-Sequence-Number: 21953 Hi, PostgreSQL 8.1 (and, back then, 7.4) have the tendency to underestimate the costs of sort operations, compared to index scans. The Backend allocates gigs of memory (we've set sort_mem to 1 gig), and then starts spilling out more Gigs of temporary data to the disk. So the execution gets - in the end - much slower compared to an index scan, and wastes lots of disk space. We did not manage to tune the config values appropriately, at least not without causing other query plans to suffer badly. Are there some nice ideas how to shift the planners preferences slightly towards index scans, without affecting other queries? There's one thing that most of those queries have in common: They include TOAST data (large strings, PostGIS geometries etc.), and I remember that there are known problems with estimating the TOAST costs. This may be part of the problem, or may be irrelevant. Thanks, Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org