Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 90FF0632716 for ; Mon, 15 Feb 2010 06:02:38 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 55636-08 for ; Mon, 15 Feb 2010 10:02:27 +0000 (UTC) X-Greylist: delayed 00:20:17.072331 by SQLgrey-1.7.6 Received: from proxy2.bredband.net (proxy2.bredband.net [195.54.101.72]) by mail.postgresql.org (Postfix) with ESMTP id 1223263261E for ; Mon, 15 Feb 2010 06:02:27 -0400 (AST) Received: from ipb2.telenor.se (195.54.127.165) by proxy2.bredband.net (7.3.140.3) id 4AD3E1BC0374734A for pgsql-performance@postgresql.org; Mon, 15 Feb 2010 10:42:08 +0100 X-SMTPAUTH-B2: X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am48APOleEtT48yuPGdsb2JhbACDBZgVDAEBAQE3LqwujkmBMIJQWwQ X-IronPort-AV: E=Sophos;i="4.49,475,1262559600"; d="scan'208";a="37391406" Received: from ua-83-227-204-174.cust.bredbandsbolaget.se (HELO mail.zigo.dhs.org) ([83.227.204.174]) by ipb2.telenor.se with ESMTP; 15 Feb 2010 10:41:05 +0100 Received: from zigo.org (localhost.localdomain [127.0.0.1]) by mail.zigo.dhs.org (Postfix) with ESMTP id 303AD48227; Mon, 15 Feb 2010 10:40:49 +0100 (CET) Received: from 192.121.104.48 (SquirrelMail authenticated user db) by zigo.org with HTTP; Mon, 15 Feb 2010 10:40:49 +0100 Message-ID: In-Reply-To: <0C60C7B5-B79F-444F-B8FB-EDD14E56F79E@silentmedia.com> References: <0C60C7B5-B79F-444F-B8FB-EDD14E56F79E@silentmedia.com> Date: Mon, 15 Feb 2010 10:40:49 +0100 Subject: Re: 8.1 -> 8.4 regression From: =?utf-8?B?RGVubmlzIEJqw7Zya2x1bmQ=?= To: "Ben Chobot" Cc: "PostgreSQL Performance" User-Agent: SquirrelMail/1.4.20-RC2 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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: 201002/234 X-Sequence-Number: 37655 Can you force 8.4 to generate the same plan as 8.1? For example by running SET enable_hashjoin = off; before you run EXPLAIN on the query? If so, then we can compare the numbers from the forced plan with the old plan and maybe figure out why it didn't use the same old plan in 8.4 as it did in 8.1. Note that the solution is not to force the plan, but it can give us more information. /Dennis > is at least one query which has degraded in performance quite a bit. Here > is the plan on 8.4.2: > http://wood.silentmedia.com/bench/842 > > Here is the very much less compact plan for the same query on 8.1.19: > http://wood.silentmedia.com/bench/8119