KaiGai,
* Kohei KaiGai (kaigai@kaigai.gr.jp) wrote:
> Now we have two options for GPU programming: CUDA or OpenCL.
> Both of libraries and drivers are provided under the proprietary license,
> so it does not fit for the core implementation of PostgreSQL, but
> extensions that shall be installed on user's responsibility.
Being able to work with libraries which are not BSD licensed doesn't
change the license under which PostgreSQL code is released. Nor does it
require PostgreSQL to be licensed in any different way from how it is
today. Where it would get a bit ugly, I agree, is for the packagers who
have to decide if they want to build against those libraries or not. We
might be able to make things a bit easier by having a startup-time
determination of if these nodes are able to be used or not. This isn't
unlike OpenSSL which certainly isn't BSD nor is it even GPL-compatible,
a situation which causes a great deal of difficulty already due to the
whole readline nonsense- but it's difficulty for the packagers, not for
the PostgreSQL project, per se.
> Because of the story, I brought up a discussion about pluggable
> planner/executor node (as a basis of GPU acceleration) in the last
> developer meeting, then has worked for custom-scan node interface.
And I'm still unconvinced of this approach and worry that it's going to
break more often than it works. That's my 2c on it, but I won't get in
the way if someone else wants to step up and support it. As I mentioned
up-thread, I'd really like to see FDW join push-down, FDW aggregate
push-down, parallel query execution, and parallel remote-FDW execution
and I don't see this CustomScan approach as the right answer to any of
those.
Thanks, Stephen