Re: 2 phase commit: performance implications?

Поиск
Список
Период
Сортировка
От David Roussel
Тема Re: 2 phase commit: performance implications?
Дата
Msg-id 43A81C8E.6010602@diroussel.xsmail.com
обсуждение исходный текст
Ответ на 2 phase commit: performance implications?  ("Andy Ballingall" <andy@areyoulocal.co.uk>)
Ответы Re: 2 phase commit: performance implications?  ("Andy Ballingall" <andy@areyoulocal.co.uk>)
Список pgsql-performance

The only issue is to ensure that a query near a boundary between two
adjacent areas behaves as though there was no partitioning. To do this, I'm
looking into using  8.1's new 2PC to allow me to selectively copy data
inserted near a boundary into the adjacent neighbouring databases, so that
this data will appear in boundary searches carried out by the neighbours.
Why not just query adjacent databases, rather than copying the data around?

If you really wanted to do this, do you need 2pc?  Once data has been uploaded to the database for region A, then asynchronously copy the data to B, C, D and E later, using a queue.  If you try to commit to all at once, then if one fails, then none has the data.

All depends on what type of data you are dealing with, how important is consistency, i.e. will it cost you money if the data is inconsistent between nodes.

Generally queuing is your friend.  You can use 2pc to ensure your queues work correctly if you like.

David

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: High context switches occurring
Следующее
От: Alan Stange
Дата:
Сообщение: Re: PostgreSQL and Ultrasparc T1