Re: Parallel Sort
От | Noah Misch |
---|---|
Тема | Re: Parallel Sort |
Дата | |
Msg-id | 20130515181137.GB234183@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: Parallel Sort (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Parallel Sort
|
Список | pgsql-hackers |
On Wed, May 15, 2013 at 08:12:34AM +0900, Michael Paquier wrote: > The concept of clause parallelism for backend worker is close to the > concept of clause shippability introduced in Postgres-XC. In the case of > XC, the equivalent of the master backend is a backend located on a node > called Coordinator that merges and organizes results fetched in parallel > from remote nodes where data scans occur (on nodes called Datanodes). The > backends used for tuple scans across Datanodes share the same data > visibility as they use the same snapshot and transaction ID as the backend > on Coordinator. This is different from the parallelism as there is no idea > of snapshot import to worker backends. Worker backends would indeed share snapshot and XID. > However, the code in XC planner used for clause shippability evaluation is > definitely worth looking at just considering the many similarities it > shares with parallelism when evaluating if a given clause can be executed > on a worker backend or not. It would be a waste to implement twice the same > thing is there is code already available. Agreed. Local parallel query is very similar to distributed query; the specific IPC cost multipliers differ, but that's about it. I hope we can benefit from XC's experience in this area. -- Noah Misch EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: