"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu> writes:
> It strikes me as a bit odd to optimize the plan for a single site,
> then break it all apart again.
Yes, that sounds pretty peculiar, especially considering that the
optimizer's choices are all about access costs. A plan generated
for entirely-local execution might be far from optimal when broken
across multiple nodes.
> My thoughts on this are to implement a two new node types: one a
> remote table, and one which represents access to a remote
> table. Remote tables have host info in them, and always be added to
> the plan with a remote-access node directly above them. Remote-access
> nodes would be seperate from their remote-table, to allow the
> communications cost to be slid up the plan tree, and merged with other
> remote-access nodes talking to the same server.
I like that approach a lot better. If the access cost estimates for the
shared-table node can be set to reflect remote communication costs,
you might actually get reasonable plans out of the optimizer...
You should not move too far with an actual implementation until you talk
to Jan about rangetable entries for sub-selects. If we are going to
invent new RTE types we may as well try to deal with that problem
at the same time.
regards, tom lane
