X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id ABF86DAF8E for ; Wed, 26 Oct 2005 21:13:44 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 52345-09 for ; Thu, 27 Oct 2005 00:13:39 +0000 (GMT) Received: from cassarossa.samfundet.no (cassarossa.samfundet.no [129.241.93.19]) by svr1.postgresql.org (Postfix) with ESMTP id 8A4E2DAFAB for ; Wed, 26 Oct 2005 21:13:41 -0300 (ADT) Received: from trofast.ipv6.sesse.net ([2001:700:300:dc03:20e:cff:fe36:a766] helo=trofast.sesse.net) by cassarossa.samfundet.no with esmtp (Exim 4.50) id 1EUvOo-0007ic-QL for pgsql-performance@postgresql.org; Thu, 27 Oct 2005 02:13:44 +0200 Received: from sesse by trofast.sesse.net with local (Exim 3.36 #1 (Debian)) id 1EUvOu-0002X1-00 for ; Thu, 27 Oct 2005 02:13:48 +0200 Date: Thu, 27 Oct 2005 02:13:48 +0200 From: "Steinar H. Gunderson" To: pgsql-performance@postgresql.org Subject: Re: Materializing a sequential scan Message-ID: <20051027001348.GA7756@uio.no> Mail-Followup-To: pgsql-performance@postgresql.org References: <20051019174544.GA32303@samfundet.no> <20051026213730.GA2295@uio.no> <12333.1130367975@sss.pgh.pa.us> <20051026232219.GA6390@uio.no> <12708.1130370782@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <12708.1130370782@sss.pgh.pa.us> X-Operating-System: Linux 2.6.14-rc5 on a x86_64 X-Message-Flag: Outlook? --> http://www.mozilla.org/products/thunderbird/ User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.01 required=5 tests=[AWL=0.010] X-Spam-Level: X-Archive-Number: 200510/405 X-Sequence-Number: 15173 On Wed, Oct 26, 2005 at 07:53:02PM -0400, Tom Lane wrote: > I don't think you're getting a correct reading for optup, but OID > 2373 is timestamp = date: > > [...] > > My recollection is that there was no such operator in 7.4; probably in > 7.4 the IN ended up using timestamp = timestamp which is hashable. You are quite correct, there is no such operator (whether by oid or by description) in my 7.4 installation. > What's not clear though is why you're getting that operator --- aren't > both sides of the IN of type "date"? Aha! Figured out the "start" column wasn't the problem after all. The problem was the "stopp" column, which was timestamp on one side and date on the other... So, it can be fixed for this instance, but this feels a bit like the pre-8.0 joins on differing data types -- is there any way to fix it? :-) /* QSteinar */ -- Homepage: http://www.sesse.net/