Re: 2 phase commit: performance implications?

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


>Why not just query adjacent databases, rather than copying the data around?

The reasons I didn't choose this way were:
1) I didn't think there's a way to write a query that can act on the data in
two
Databases as though it was all in one, and I didn't want to get into merging
multiple database query results on the Application side. I'd rather just
have all the needed data sitting in a single database so that I can perform
whatever query I like without complication.
2) Most database accesses are reads, and I didn't want a big network
overhead for these, especially since I'm aiming for each database to be
entirely RAM resident.

>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. 

I've always assumed that my data needed to be consistent. I guess there are
some circumstances where it isn't really a problem, but each would need to
be carefully evaluated. The easy answer is to say 'yes, it must be
consistent'.

>If you try to commit to all at once, then if one fails, then none has the
data.

Yes, I'd prefer things to be that way in any event.

Regards,
Andy


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

Предыдущее
От: "Alban Medici \(NetCentrex\)"
Дата:
Сообщение: Re: [GENERAL] need help
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Windows performance again