KaiGai, * Kohei KaiGai (kai...@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
Description: Digital signature