On Wed, Nov 06, 2019 at 11:01:37AM -0700, AJG wrote:
From what I have read and benchmarks seen..
FPGA shines for writes (and up to 3x (as opposed to 10x claim) real world
for queries from memory)
GPU shines/outperforms FPGA for reads. There is a very recent and
interesting academic paper[1] on High Performance GPU B-Tree (vs lsm) and
the incredible performance it gets, but I 'think' it requires NVIDIA (so no
easy/super epyc+gpu+hbm on-chip combo solution then ;) ).
Doesn't both FPHGA and GPU going to require changes to executor from pull to
push to get real benefits from them? Isnt that something Andres working on
(pull to push)?
I think it very much depends on how the FPA/GPU/... is used.
If we're only talking about FPGA I/O acceleration, essentially FPGA
between the database and storage, it's likely possible to get that
working without any extensive executor changes. Essentially create an
FPGA-aware variant of SeqScan and you're done. Or an FPGA-aware
tuplesort, or something like that. Neither of this should require
significant planner/executor changes, except for costing.
What really is exciting is UPMEM (little 500mhz processors on the memory),
cost will be little more than memory cost itself, and shows up to 20x
performance improvement on things like index search (from memory). C
library, claim only needs few hundred lines of code to integrate from
memory, but not clear to me what use cases it can also be used for than ones
they show benchmarks for.
Interesting, and perhaps interesting for in-memory databases.
[1] https://escholarship.org/content/qt1ph2x5td/qt1ph2x5td.pdf?t=pkvkdm
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
