2014-03-02 9:51 GMT+09:00 Stephen Frost <sfr...@snowman.net>: > 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. > As you mentioned, it is a headache for packagers, and does not make sense for us if packager disabled the feature that requires proprietary drivers. In fact, Fedora / RHEL does not admit to distribute software under the none open source software license. Obviously, nvidia's cuda is a library being distributed under the proprietary license, thus out of the scope for the Linux distributors. It also leads them to turn off the feature that shall be linked with proprietary drivers. All we can do is to implement these features as extension, then offer an option for users to use or not to use.
>> 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. > It's right approach for FDW functionality enhancement, I never opposed to. What I'd like to implement is GPU acceleration that can perform on regular tables, not only foreign tables. Also, regarding to the backlog in the developer meeting, pluggable executor node is also required feature by PG-XC folks to work their project with upstream. I think custom-scan feature is capable to host these requirement, and does not prevent enhancement FDW features. Thanks, -- KaiGai Kohei <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
