> Or, taking the example of a GpuScan node, it's essentially impossible > to persuade the planner to delegate any expensive function calculations, > aggregates, etc to such a node; much less teach it that that way is cheaper > than doing such things the usual way. So yeah, KaiGai-san may have a > module that does a few things with a GPU, but it's far from doing all or > even very much of what one would want. > Why do we need to run all the functions on GPU device? PG-Strom simply gives up to inject CustomPath if required qualifier contains unsupported functions or data types, thus, these workloads are executed as usual. I don't intend 100% coverage by GPU. That's no matter. People who use massive numerical/mathematical workload will love GPU.
> Now, as part of the upper-planner-rewrite business that I keep hoping to > get to when I'm not riding herd on bad patches, it's likely that we might > have enough new infrastructure soon that that particular problem could > be solved. But there would just be another problem after that; a likely > example is not having adequate statistics, or sufficiently fine-grained > function cost estimates, to be able to make valid choices once there's > more than one way to do such calculations. (I'm not really impressed by > "the GPU is *always* faster" approaches.) Significant improvements of > that sort are going to take core-code changes. > We never guarantee the interface compatibility between major version up. If we add/modify interface on v9.6, it is duty for developer of extensions to follow the new version, even not specific to custom-scan provider. If v9.6 adds support fine-grained function cost estimation, I also have to follow the feature, but it is natural. > Even worse, if there do get to be any popular custom-scan extensions, > we'll break them anytime we make any nontrivial planner changes, because > there is no arms-length API there. A trivial example is that even adding > or changing any fields in struct Path will necessarily break custom scan > providers, because they build Paths for themselves with no interposed API. > I cannot understand... If Path field gets changed, it is duty of extension to follow the core change. We usually add/modify API specifications on major version up. For example, I remember ProcessUtility_hook has been changed a few times in the last several years. Thanks, -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
