
PGStrom: GPU-accelerated PostgreSQL - DrJokepu
https://wiki.postgresql.org/wiki/PGStrom
======
headgasket
It actually works with openCL. I had to do a few changes to make it work on
MacOSX, but I beleive the language barrier and the fact that his project is in
a flux and I came out of the blue caused these few lines to not merge. Please
see my fork of his dev branch, that works with 9.5dev: [https://github.com/pg-
strom/devel/pull/144](https://github.com/pg-strom/devel/pull/144)

correction: those changes to compile on macox did get pulled so
[https://github.com/pg-strom/devel](https://github.com/pg-strom/devel) should
build with openCL on your mac to link with 9.5dev.

------
tsuru
Here are a couple more resources where the lead gives a bit more description:

[http://on-demand.gputechconf.com/gtc/2015/presentation/S5276...](http://on-
demand.gputechconf.com/gtc/2015/presentation/S5276-Kohei-KaiGai.pdf)

[http://www.slideshare.net/kaigai/gpgpu-accelerates-
postgresq...](http://www.slideshare.net/kaigai/gpgpu-accelerates-postgresql)

edit: His slideshare page
[http://www.slideshare.net/kaigai](http://www.slideshare.net/kaigai) has even
more recent presentations. I've only had time to skim much of slides, but it
seems he's flip-flopped a couple of times between OpenCL and CUDA

------
tempodox
If I simplify this & other news to the statement, “our GPUs are Turing-
complete”, then one question seems to follow logically: When will our CPUs
become multi-core on the scale of a GPU? Or is that a stupid question that
only looks logical?

~~~
belorn
When/If HP finish _the machine_ with 2500 cores, that will basically result in
the CPU becoming as parallel as GPU's.

~~~
Symmetry
What NVidia calls a core and what Intel calls a core really aren't comparable.
If you go by the Intel definition which is more or less "Capable of
independantly issuing an instruction" then you might find 15 cores in a Xeon
versus 24 SMM "cores" in the top NVidia chip. Going by the NVidia definition
which is more or less "Things that can execute instructions from a queue"
NVidia would have 3072 cores in it's top chip and Intel would have 120 cores
or "execution ports" as they call them.

------
michaelt
I was under the impression that to get the speed benefits of CUDA you had to
coalesce memory access. Does anyone know how nested loop joins can use indexes
without messing up the memory access coalescing?

------
lugus35
What would be nice is a document which would _explain_ how to convert queries
to use the GPU as its best, a document which would not require its reader to
be a GPU geek nor a Postgresql expert. A technology can only succeed when the
average programmer can use it without doing much errors, or can find quickly a
solution using google.

~~~
logicallee
>how to convert queries to use the GPU as its best, a document which would not
require its reader to be a GPU geek nor a Postgresql expert

Uh, isn't this like asking "how do I do calculus without being a calculus
geek"? I mean it's specialized - how do you get around being a "GPU geek" if
you're coding for a GPU "at its best"?

~~~
spacemanmatt
Agreed. This is squarely aimed at database geeks which is a fairly esoteric
audience. It's gonna get geeky.

------
irremediable
I like it that there's lots of robust criticism in the comments, but I think
people are maybe being a little pessimistic. This is pretty exciting, isn't
it? GPUs have sped things up in a lot of technologies, and I'm intrigued to
see what they can do for databases.

------
ck2
What the what? 10 times faster for one join?

[https://wiki.postgresql.org/images/5/50/PGStrom_Fig_MicroBen...](https://wiki.postgresql.org/images/5/50/PGStrom_Fig_MicroBenchGpuJoin.png)

Or am I reading that incorrectly?

How is that possible?

~~~
mslot
Joining a large number of tables is a sweet spot for PGStrom where in which
there are a lot of parallelizable computations. For a lot of queries it can
actually be slower.

~~~
calpaterson
Hopefully the query planner would choose whether or not to use PGStrom for a
specific query.

Many interesting queries in normalised databases involve a lot of joins. In a
BCNF database most interesting queries use 3 or more joins. Whether or not I
believe the microbenchmarks is another thing :)

------
iopq
I got excited until I saw CUDA instead of OpenCL...

~~~
ogrisel
And the use of GPL license which means that this code cannot be contributed
upstream to PostgreSQL itself because it uses a more liberal license:
[http://opensource.org/licenses/postgresql](http://opensource.org/licenses/postgresql).

~~~
ksec
Ok this is annoying, why do they choose GPL instead of something similar to
PostGre?

------
spacemanmatt
This is cool but is there actual news about the project other than existence?

~~~
jpgvm
Unfortunately most of the discussion seems to be going down in Japanese.

That said if you don't mind just reading diffs you can get an idea of the
state of the project by taking a gander at their github:
[https://github.com/pg-strom/devel](https://github.com/pg-strom/devel)

------
kyloon
This reminds me of MapD ([http://www.mapd.com](http://www.mapd.com)), though I
am not sure which database MapD builds their stuffs on.

------
mosselman
I imagine this isn't production ready. Or is it? It looks very cool and like a
good direction to go in. You'd need a VPS with GPU access though.

------
javajosh
Anyone have a sense for the kinds of queries this would actually help with?

~~~
pcwalton
Probably queries that have a lot of brute-force comparisons involving full
table scans. "select foo from bar where baz > 30" with no index, for example.

(Source: I've done a fair bit of experimentation in GPU queries in the domain
of CSS selector matching.)

~~~
radiowave
Interesting thought. I was assuming that the impressive performance figures
based on joining 10 tables together would be making use of indexes, because
with full table scans it might be difficult to keep the GPUs fed with data.

------
victorbojica
does anyone know if this would work with postgis?

