PG-Strom: SSD-To-GPU Direct SQL Execution

Re:PG-Strom: SSD-To-GPU Direct SQL Execution by raverbashing on Sunday June 04, 2017 @11:14AM (#14481948)

Wondering how much the "moving data to the GPU" overhead won't help to make things significantly faster

[ Parent | on HN ]

Re:PG-Strom: SSD-To-GPU Direct SQL Execution by cjhanks on Sunday June 04, 2017 @02:14PM (#14482704)

This was posted on an old HN -http://kaigai.hatenablog.com/entry/2016/09/08/003556

The major performance gain is doing SSD-to-GPU direct memory access bypassing the need for data to needlessly transfer over PCI-Express twice.

[ Parent | on HN ]

Re:PG-Strom: SSD-To-GPU Direct SQL Execution by blopeur on Sunday June 04, 2017 @11:27AM (#14482014)

I think that, with the emergence of OpenCapi and the like of CCIX, we will see more and more offloading to specialised HW as generic CPU are not able to cope with the required performance and amount of data. If you look at Infiniband roadmap, they plan to hit 1 Tb/S within a couple of years. And no core dedication a la DPDK will allow generic CPU to handle that. The heterogeneous hardware platforms are becoming the norm really quickly.

[ Parent | on HN ]

Re:PG-Strom: SSD-To-GPU Direct SQL Execution by throwaway91111 on Sunday June 04, 2017 @12:57PM (#14482370)

Really depends on the shape of the data and query at hand. If you're doing aggregate computations over million/billions of scalar-sized rows, it could be quite fast. However joining two cold tables will still be more limited by schema and disk read than anything.

[ Parent | on HN ]

Re:PG-Strom: SSD-To-GPU Direct SQL Execution by arnon on Sunday June 04, 2017 @02:50PM (#14482877)

Unless you're doing skipping and indexing properly....

[ Parent | on HN ]