Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 35891633431 for ; Thu, 7 Jan 2010 10:29:36 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 55150-01 for ; Thu, 7 Jan 2010 14:29:17 +0000 (UTC) X-Greylist: delayed 00:23:36.382333 by SQLgrey-1.7.6 Received: from mail.erwied.eu (mail.erwied.eu [85.214.80.157]) by mail.postgresql.org (Postfix) with ESMTP id 814B06331F2 for ; Thu, 7 Jan 2010 10:29:25 -0400 (AST) Received: from [188.100.142.174] (helo=erwied.dns2go.com ident=mail) by mail.erwied.eu with esmtpsa (Exim 4.71#1) id 1NSszh-0005dF-Kn ; Thu, 07 Jan 2010 15:05:45 +0100 Received: from port-87-234-32-189.static.qsc.de ([87.234.32.189] helo=joe-lifebook.internal) by erwied.dns2go.com with esmtpsa (Exim 4.71#1) id 1NSszc-0000Jt-3d ; Thu, 07 Jan 2010 15:05:40 +0100 Date: Thu, 7 Jan 2010 15:05:35 +0100 From: Jochen Erwied Organization: Creative Chaos Computing X-Priority: 3 (Normal) Message-ID: <26014999.20100107150535@erwied.eu> To: Lefteris CC: pgsql-performance@postgresql.org Subject: Re: Air-traffic benchmark In-Reply-To: <852badbc1001070547p48b47175vf87efc473e3bd41b@mail.gmail.com> References: <852badbc1001070438j36eb10d3qa22398ffcbef405f@mail.gmail.com> <4B45E36E.4040706@tweakers.net> <852badbc1001070547p48b47175vf87efc473e3bd41b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.185 tagged_above=-10 required=5 tests=BAYES_40=-0.185 X-Spam-Level: X-Archive-Number: 201001/94 X-Sequence-Number: 36974 Thursday, January 7, 2010, 2:47:36 PM you wrote: > so I understand from all of you that you don't consider the use of 25k > for sorting to be the cause of the slowdown? Probably I am missing Maybe you are reading the plan wrong: - the sort needs only 25kB of memory, and finishes in sub-second time,=20 mainly because the sort only sorts the already summarized data, and not the whole table =20 - the sequential scan takes 346 seconds, and thus is the major factor in time to finish! =20 So the total query time is 371 seconds, of which 346 are required to=20 completely scan the table once. --=20 Jochen Erwied | home: jochen@erwied.eu +49-208-38800-18, FAX: -19 Sauerbruchstr. 17 | work: joe@mbs-software.de +49-2151-7294-24, FAX: -50 D-45470 Muelheim | mobile: jochen.erwied@vodafone.de +49-173-5404164