Skip site navigation (1) Skip section navigation (2)

Re: Materializing a sequential scan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Steinar H(dot) Gunderson" <sgunderson(at)bigfoot(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Materializing a sequential scan
Date: 2005-10-27 00:51:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
"Steinar H. Gunderson" <sgunderson(at)bigfoot(dot)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...


> 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

In response to


pgsql-performance by date

Next:From: Steinar H. GundersonDate: 2005-10-27 00:57:15
Subject: Re: Materializing a sequential scan
Previous:From: Steinar H. GundersonDate: 2005-10-27 00:13:48
Subject: Re: Materializing a sequential scan

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group