KaiGai, * Stephen Frost (sfr...@snowman.net) wrote: > 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.
Alright, having heard from Robert (thanks!) regarding his thoughts (which are pretty similar to my own, though he doesn't anticipate issues with API changes), I'm going to step back a bit form the above position. > 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. In accordance with the above, what I'd like to see with this patch is removal of the postgres_fdw changes and any changes which were for that support. In addition, I'd like to understand why 'ctidscan' makes any sense to have as an example of what to use this for- if that's valuable, why wouldn't we simply implement that in core? I do want an example in contrib of how to properly use this capability, but I don't think that's it. For one thing, an example where you could have this CustomScan node calling other nodes underneath would be interesting. I realize the CTID scan can't do that directly but I would think your GPU-based system could; after all, if you're running a join or an aggregate with the GPU, the rows could come from nearly anything. Have you considered that, or is the expectation that users will just go off and access the heap and/or whatever indexes directly, like ctidscan does? How would such a requirement be handled? Thanks, Stephen
Description: Digital signature