Martijn van Oosterhout wrote:
On Tue, Apr 11, 2006 at 04:02:07PM -0700, Mischa Sandberg wrote:
Anybody on this list hear/opine anything pf the GPUSort project for
postgresql? I'm working on a radix-sort subcase for tuplesort, and there
are similarities.
http://www.andrew.cmu.edu/user/ngm/15-823/project/
I've heard it meantioned, didn't know they'd got it working. However,
none of my database servers have a 3D graphics anywhere near the power
they suggest in the article.
Is this of practical use for run-of-the-mill video cards?
Short answer: maybe.
Long answer: we're shipping a server (appliance) product built on stock
rackmount hardware, that includes an ATI Rage (8MB) with nothing to do. Much of
what the box does is a single cpu-bound process, sorting maillog extracts. The
GPU is an asset, even at 8MB; the headwork is in mapping/truncating sort keys
down to dense ~32bit prefixes; and in making smooth judgements as to when to
give the job to (a) the GPU (b) quicksort (c) a tiny bitonic sort in the SSE2
registers.
Any of this would apply to postgres, if tuplesort.c can tolerate a preprocessing
step that looks for special cases, and degrades gracefully into the standard
case. I'm guessing that there are enough internal sorts (on oid, for example)
having only small, memcmp-able sort keys, that this is worth adding in.
--
Engineers think that equations approximate reality.
Physicists think that reality approximates the equations.
Mathematicians never make the connection.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match