Simon, * Simon Riggs (si...@2ndquadrant.com) wrote: > On 8 May 2014 01:49, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote: > >From your description, my understanding is that you would like to > stream data from 2 standard tables to the GPU, then perform a join on > the GPU itself. > > I have been told that is not likely to be useful because of the data > transfer overheads.
That was my original understanding and, I believe, the case at one
point, however...
> Or did I misunderstand, and that this is intended to get around the
> current lack of join pushdown into FDWs?
I believe the issue with the transfer speeds to the GPU have been either
eliminated or at least reduced to the point where it's practical now.
This is all based on prior discussions with KaiGai- I've not done any
testing myself. In any case, this is exactly what they're looking to
do, as I understand it, and to do the same with aggregates that work
well on GPUs.
> Can you be specific about the actual architecture you wish for, so we
> can understand how to generalise that into an API?
It's something that *could* be done with FDWs, once they have the
ability to have join push-down and aggregate push-down, but I (and, as I
understand it, Tom) feel isn't really the right answer for this because
the actual *data* is completely under PG in this scenario. It's just
in-memory processing that's being done on the GPU and in the GPU's
memory.
KaiGai has speculated about other possibilities (eg: having the GPU's
memory also used as some kind of multi-query cache, which would reduce
the transfer costs, but at a level of complexity regarding that cache
that I'm not sure it'd be sensible to try and do and, in any case, could
be done later and might make sense independently, if we could make it
work for, say, a memcached environment too; I'm thinking it would be
transaction-specific, but even that would be pretty tricky unless we
held locks across every row...).
Thanks,
Stephen
signature.asc
Description: Digital signature
