To: "Steinar H. Gunderson" <sgunderson@bigfoot.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Materializing a sequential scan 
In-reply-to: <20051027001348.GA7756@uio.no> 
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>
	<20051027001348.GA7756@uio.no>
Comments: In-reply-to "Steinar H. Gunderson" <sgunderson@bigfoot.com>
	message dated "Thu, 27 Oct 2005 02:13:48 +0200"
Date: Wed, 26 Oct 2005 20:51:03 -0400
Message-ID: <13034.1130374263@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Steinar H. Gunderson" <sgunderson@bigfoot.com> writes:
> 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...

Ah-hah.

> 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? :-)

I have some ideas in the back of my head about supporting
cross-data-type hashing.  Essentially this would require that the hash
functions for two types be compatible in that they generate the same
hash value for two values that would be considered equal.  (For
instance, the integer hash functions already have the property that
42::int2, 42::int4, and 42::int8 will all generate the same hash code.
The date and timestamp hash functions don't have such a property ATM,
but probably could be made to.)  For types that share a hash coding
convention, cross-type equality functions could be marked hashable.
This is all pretty handwavy at the moment though, and I don't know
how soon it will get done.

			regards, tom lane