From: | Yeb Havinga <yebhavinga(at)gmail(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Eliot Gable <egable+pgsql-performance(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: GPU Accelerated Sorting |
Date: | 2010-08-30 19:25:38 |
Message-ID: | 4C7C05B2.7030207@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Greg Smith wrote:
> This comes up every year or so. The ability of GPU offloading to help
> with sorting has to overcome the additional latency that comes from
> copying everything over to it and then getting all the results back.
> If you look at the typical types of sorting people see in PostgreSQL,
> it's hard to find ones that are a) big enough to benefit from being
> offloaded to the GPU like that, while also being b) not so
> bottlenecked on disk I/O that speeding up the CPU part matters. And
> if you need to sort something in that category, you probably just put
> an index on it instead and call it a day.
>
> If you made me make a list of things I'd think would be worthwhile to
> spend effort improving in PostgreSQL, this would be on the research
> list, but unlikely to even make my personal top 100 things that are
> work fiddling with.
Related is 'Parallelizing query optimization'
(http://www.vldb.org/pvldb/1/1453882.pdf) in which they actually
experiment with PostgreSQL. Note that their target platform is general
purpose CPU, not a SIMD GPU processor.
-- Yeb
From | Date | Subject | |
---|---|---|---|
Next Message | Clemens Eisserer | 2010-08-30 20:41:59 | Re: Performance on new 64bit server compared to my 32bit desktop |
Previous Message | Eliot Gable | 2010-08-30 18:49:27 | Re: GPU Accelerated Sorting |