Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 6DEC29FB2A4 for ; Mon, 30 Oct 2006 11:51:11 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 51734-05 for ; Mon, 30 Oct 2006 11:51:02 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from cassarossa.samfundet.no (cassarossa.samfundet.no [129.241.93.19]) by postgresql.org (Postfix) with ESMTP id 3F8949FB2DD for ; Mon, 30 Oct 2006 11:51:01 -0400 (AST) Received: from trofast.ipv6.sesse.net ([2001:700:300:1803:20e:cff:fe36:a766] helo=trofast.sesse.net) by cassarossa.samfundet.no with esmtp (Exim 4.50) id 1GeZPc-0006sw-Ti; Mon, 30 Oct 2006 16:50:57 +0100 Received: from sesse by trofast.sesse.net with local (Exim 3.36 #1 (Debian)) id 1GeZOf-00024d-00; Mon, 30 Oct 2006 16:49:57 +0100 Date: Mon, 30 Oct 2006 16:49:57 +0100 From: "Steinar H. Gunderson" To: Mattias Kregert Cc: pgsql-performance@postgresql.org Subject: Re: Strange plan in pg 8.1.0 Message-ID: <20061030154957.GA7834@uio.no> Mail-Followup-To: Mattias Kregert , pgsql-performance@postgresql.org References: <200610301205.08087.mattias@kregert.se> <20061030122733.GA6357@uio.no> <003301c6fc2f$57e2c660$09000a0a@kregert.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <003301c6fc2f$57e2c660$09000a0a@kregert.se> X-Operating-System: Linux 2.6.17.11 on a x86_64 X-Message-Flag: Outlook? --> http://www.mozilla.org/products/thunderbird/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200610/614 X-Sequence-Number: 21743 On Mon, Oct 30, 2006 at 03:26:09PM +0100, Mattias Kregert wrote: > On the left side it is text, and on the right side it is varchar(10). > Casting left side to varchar(10) does not help, in fact it makes things > even worse: The cast to ::text vanishes in a puff of logic, but the plan > gets bigger and even slower (20-25 seconds). Casting definitely won't help it any; it was more a question of having the types in the _tables_ be the same. Anyhow, this might be a red herring; others might have something more intelligent to say in this matter. By the way, does it use an index scan if you turn off sequential scans (set enable_seqscan = false)? /* Steinar */ -- Homepage: http://www.sesse.net/