Re: [HACKERS] Mariposa
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Mariposa |
Дата | |
Msg-id | 3813.933634289@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Mariposa ("Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>) |
Список | pgsql-hackers |
"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
В списке pgsql-hackers по дате отправления: