Re: Materializing a sequential scan - Mailing list pgsql-performance

From Tom Lane
Subject Re: Materializing a sequential scan
Date
Msg-id 13034.1130374263@sss.pgh.pa.us
Whole thread Raw
In response to Re: Materializing a sequential scan  ("Steinar H. Gunderson" <sgunderson@bigfoot.com>)
Responses Re: Materializing a sequential scan  ("Steinar H. Gunderson" <sgunderson@bigfoot.com>)
List pgsql-performance
"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

pgsql-performance by date:

Previous
From: "Steinar H. Gunderson"
Date:
Subject: Re: Materializing a sequential scan
Next
From: "Steinar H. Gunderson"
Date:
Subject: Re: Materializing a sequential scan