KaiGai,
* Stephen Frost (sfrost@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