4 ms·

One thing that's missing is GPU acceleration, like MAPD Being able to group by a column and do a count(*) in 100ms is mind blowing. I would pay for a MAPD-styl

One thing that's missing is GPU acceleration, like MAPD Being able to group by a column and do a count(*) in 100ms is mind blowing. I would pay for a MAPD-style backend for postgresql.

throwaway082729 7y ago
Isn't BlazingDB working on something like this?
sitkack 7y ago
While a GPU has excellent memory bandwidth and lots of parallel processors, its connection to the rest of the system makes it not ideal for database work. If you can have bit set indexes on the GPU, maybe. But data transfer and kernel launch will dominate in the timing. But, dual socket EPYC systems have ~300GB/s of memory bandwidth to main memory. 1-4TB machines are available right now.
- derefr 7y ago
  Still works if your goal is generating heavy OLAP reports, and your reports can be calculated per-shard and then reduced at the end. If your query can be expressed in ten bytes, and the answer can be expressed in ten bytes, but in between there’s several TBs of data to run through in tons and tons of parallel-sequential passes that don’t involve any data that’s not already on the GPU, a GPU DBMS cluster seems optimal. —— For more regular workloads, though, its seems like a proper GPU-targeted DBMS architecture wouldn’t use single “huge” GPUs, but rather would shard data (and thus workloads) across a cluster of commodity boxes with commodity GPUs, such that each GPU has just enough data held on it for query traffic to that GPU to barely saturate the PCI-e lanes. Which is another way to say: maybe Intel’s Phi was ahead of its time. Consider a Phi as an entire computer (because it is, and you can program it as such), and a computer containing more than one of them as a cluster backplane with a shared SAN (because it is, and you can access it from the Phi’s as such.) I have a feeling this architecture will see a comeback, either in this form, or in the (roughly equivalent) form of backplane-connected clusters of highly-multicore Single-board Computers.
- scott_s 7y ago
  I wrote a paper on pretty much that problem: "Evaluation of Streaming Aggregation on Parallel Hardware Architectures", https://www.scott-a-s.com/files/debs2010.pdf https://www.scott-a-s.com/files/debs2010.pdf Conclusion in brief: in order to "win" when trying to use an off-board accelerator, you need to look at each byte transferred more than once. If you only look at a byte once to compute your result, then it's going to be faster to just do the computation on the CPU. The reason: the up-front cost of transferring that byte is high. The win comes from reusing that byte many times in the massively parallel architecture on the accelerator.
- asgiknionio 7y ago
  Take a look at this: https://www.amd.com/en/products/professional-graphics/radeon-pro-ssg https://www.amd.com/en/products/professional-graphics/radeon... With that technology, maybe it would be possible to keep a complete replica on the GPU.
michelpp 7y ago
pg-strom does that and more: https://github.com/heterodb/pg-strom https://github.com/heterodb/pg-strom It can be used to optimize things like counts and other aggregates over a standard postgres table, it also provides a foreign data wrapper column store to optimize certain analytical queries by greatly speeding up GPU transfers. Additionally it can use the GPU as a "co-processor" to do large amounts of row filtering before handing the final work off to the CPU.

One thing that's missing is GPU acceleration, like MAPD Being able to group by a column and do a count(*) in 100ms is mind blowing. I would pay for a MAPD-style backend for postgresql.

throwaway082729 7y ago

Isn't BlazingDB working on something like this?

sitkack 7y ago

While a GPU has excellent memory bandwidth and lots of parallel processors, its connection to the rest of the system makes it not ideal for database work. If you can have bit set indexes on the GPU, maybe. But data transfer and kernel launch will dominate in the timing. But, dual socket EPYC systems have ~300GB/s of memory bandwidth to main memory. 1-4TB machines are available right now.

derefr 7y ago
Still works if your goal is generating heavy OLAP reports, and your reports can be calculated per-shard and then reduced at the end. If your query can be expressed in ten bytes, and the answer can be expressed in ten bytes, but in between there’s several TBs of data to run through in tons and tons of parallel-sequential passes that don’t involve any data that’s not already on the GPU, a GPU DBMS cluster seems optimal. —— For more regular workloads, though, its seems like a proper GPU-targeted DBMS architecture wouldn’t use single “huge” GPUs, but rather would shard data (and thus workloads) across a cluster of commodity boxes with commodity GPUs, such that each GPU has just enough data held on it for query traffic to that GPU to barely saturate the PCI-e lanes. Which is another way to say: maybe Intel’s Phi was ahead of its time. Consider a Phi as an entire computer (because it is, and you can program it as such), and a computer containing more than one of them as a cluster backplane with a shared SAN (because it is, and you can access it from the Phi’s as such.) I have a feeling this architecture will see a comeback, either in this form, or in the (roughly equivalent) form of backplane-connected clusters of highly-multicore Single-board Computers.
scott_s 7y ago
I wrote a paper on pretty much that problem: "Evaluation of Streaming Aggregation on Parallel Hardware Architectures", https://www.scott-a-s.com/files/debs2010.pdf https://www.scott-a-s.com/files/debs2010.pdf Conclusion in brief: in order to "win" when trying to use an off-board accelerator, you need to look at each byte transferred more than once. If you only look at a byte once to compute your result, then it's going to be faster to just do the computation on the CPU. The reason: the up-front cost of transferring that byte is high. The win comes from reusing that byte many times in the massively parallel architecture on the accelerator.
asgiknionio 7y ago
Take a look at this: https://www.amd.com/en/products/professional-graphics/radeon-pro-ssg https://www.amd.com/en/products/professional-graphics/radeon... With that technology, maybe it would be possible to keep a complete replica on the GPU.

michelpp 7y ago

pg-strom does that and more: https://github.com/heterodb/pg-strom https://github.com/heterodb/pg-strom It can be used to optimize things like counts and other aggregates over a standard postgres table, it also provides a foreign data wrapper column store to optimize certain analytical queries by greatly speeding up GPU transfers. Additionally it can use the GPU as a "co-processor" to do large amounts of row filtering before handing the final work off to the CPU.