* Robert Haas (robertmh...@gmail.com) wrote: > I am not sure what your point is here. Here's mine: if we can strip > this down to the executor support plus the most minimal planner > support possible, we might be able to get *something* committed. Then > we can extend it in subsequent commits.
I guess my point is that I see this more-or-less being solved already by
FDWs, but that doesn't address the case when it's a local table, so
perhaps there is something useful our of a commit that allows
replacement of a SeqScan node (which presumably would also be costed
differently).
> You seem to be saying there's no value in getting anything committed
> unless it handles the scan-substituting-for-join case. I don't agree.
> Incremental commits are good, whether they get you all the way to
> where you want to be or not.
To be honest, I think this is really the first proposal to replace
specific Nodes, rather than provide a way for a generic Node to exist
(which could also replace joins). While I do think it's an interesting
idea, and if we could push filters down to this new Node it might even
be worthwhile, I'm not sure that it actually moves us down the path to
supporting Nodes which replace joins.
Still, I'm not against it.
Thanks,
Stephen
signature.asc
Description: Digital signature
