RE: Transactions involving multiple postgres foreign servers, take 2
От | tsunakawa.takay@fujitsu.com |
---|---|
Тема | RE: Transactions involving multiple postgres foreign servers, take 2 |
Дата | |
Msg-id | TYAPR01MB29903B5DB72FAFA6A1B072EEFE330@TYAPR01MB2990.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Transactions involving multiple postgres foreign servers, take 2 (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>) |
Ответы |
Re: Transactions involving multiple postgres foreign servers, take 2
|
Список | pgsql-hackers |
From: Masahiko Sawada <masahiko.sawada@2ndquadrant.com> > To avoid misunderstanding, I didn't mean to disregard the performance. > I mean especially for the transaction management feature it's > essential to work fine even in failure cases. So I hope we have a > safe, robust, and probably simple design for the first version that > might be low performance yet though but have a potential for > performance improvement and we will be able to try to improve > performance later. Yes, correctness (safety?) is a basic premise. I understand that given the time left for PG 14, we haven't yet given upa sound design that offers practical or normally expected performance. I don't think the design has not well thought yetto see if it's simple or complex. At least, I don't believe doing "send commit request, perform commit on a remote server,and wait for reply" sequence one transaction at a time in turn is what this community (and other DBMSs) tolerate. A kid's tricycle is safe, but it's not safe to ride a tricycle on the road. Let's not rush to commit and do ourbest! Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: