On Jun 11, 2007, at 4:31 AM, Alban Hertroys wrote:
Alexander Staubo wrote:
On 6/8/07, Billings, John <[EMAIL PROTECTED]> wrote:
If so which part of the database, and what kind of parallel
algorithms would be used?
GPUs are parallel vector processing pipelines, which as far as I can
tell do not lend themselves right away to the data structures that
PostgreSQL uses; they're optimized for processing high volumes of
homogenously typed values in sequence.
But wouldn't vector calculations on database data be sped up? I'm
thinking of GIS data, joins across ranges like matching one (start,
end)
range with another, etc.
I realize these are rather specific calculations, but if they're
important to your application...
OTOH modern PC GPU's are optimized for pushing textures; basically
transferring a lot of data in as short a time as possible. Maybe
it'd be
possible to move result sets around that way? Do joins even maybe?
OTOH databases might not be running on modern desktop PC's with the
GPU investment.
Rather they might be running on a "headless" machine that has little
consideration for the GPU.
It might make an interesting project, but I would be really depressed
if I had to go buy an NVidia card instead of investing in more RAM to
optimize my performance! <g>
---------------------------(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
