> > So it seems reasonable to have a way to define/declare what is > > possible and what is not. But my take is that adding a new column to > > pg_operator for every CustomJoin node is probably out of the question, > > hence my suggestion to list the operators we know it can work with. > > It does seem like there should be some work done in this area, as Tom > mentioned, > to avoid needing to have more columns to track how equality can be done. > I do wonder just how we'd deal with this when it comes to GPUs as, presumably, > the code to implement the equality for various types would have to be written > in CUDA-or-whatever. > GPU has workloads likes and dislikes. It is a reasonable idea to list up operators (or something else) that have advantage to run on custom-path. For example, numeric calculation on fixed-length variables has greate advantage on GPU, but locale aware text matching is not a workload suitable to GPUs. It may be a good hint for planner to pick up candidate paths to be considered.
Thanks, -- NEC OSS Promotion Center / 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
