From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | Christopher Browne <cbbrowne(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Will PostgreSQL get ported to CUDA? |
Date: | 2008-01-31 13:36:15 |
Message-ID: | 20080131133615.GB21660@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 30, 2008 at 08:27:47PM +0000, Gregory Stark wrote:
> "Christopher Browne" <cbbrowne(at)gmail(dot)com> writes:
> > This was based on GPUSort:
> > http://gamma.cs.unc.edu/GPUSORT/
>
> I looked briefly at GPUSort a while back. I couldn't see how to shoehorn into
> POstgres the assumption that you're always sorting floating point numbers. You
> would have to add some property of some data types that mapped every value to
> a floating point value. I suppose we could add that as a btree proc entry for
> specific data types but it would be a pretty radical change.
Not new though. The idea has been floated to create such functions
(only mapping to integers) and have the postgres sort code first
compare the integers and only if they're equal to run the actual
comparison function. The idea being to avoid function call overhead.
It would mostly be a win for comparing strings since you then don't
need to lookup the collation tables as often.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Those who make peaceful revolution impossible will make violent revolution inevitable.
> -- John F Kennedy
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-01-31 13:42:12 | Re: [PATCHES] Proposed patch: synchronized_scanning GUC variable |
Previous Message | Alvaro Herrera | 2008-01-31 12:31:45 | Re: [PATCHES] Better default_statistics_target |