Re: Beating Oracle
От | buhrow@lothlorien.nfbcal.org (Brian Buhrow) |
---|---|
Тема | Re: Beating Oracle |
Дата | |
Msg-id | 200203010423.UAA08481@lothlorien.nfbcal.org обсуждение исходный текст |
Ответ на | Beating Oracle (Bruce Badger <bbadger@BadgerSE.com>) |
Ответы |
INSERTing and UPDATEing records with libpq
|
Список | pgsql-interfaces |
Hello Bruce. I'd be willing to bet that if a firewall is involved, it's been especially tuned for Oracle, whereas special rules weren't set for Postgres. As soon as those rules get put in, things will probably be very equivalent. -Brian On Mar 2, 10:15am, Bruce Badger wrote: } Subject: Re: Beating Oracle } Bruce Momjian wrote: } } >Bruce Badger wrote: } > } >>Tom Lane wrote: } >> } >>>Bruce Badger <bbadger@BadgerSE.com> writes: } >>> } >>>>Due to network glitch, a PostgreSQL connection over IP is being dropped. } >>>> } >>>Perhaps there is something wrong with your TCP stacks. I do not think } >>>it's Postgres' responsibility to second-guess the network transport } >>>code... } >>> } >>> regards, tom lane } >>> } >>Not *my* stack, BTW, but that aside I agree with you. The people } >>involved suspect that a firewall is causing the problem. } >> } >>The thing is that from their point of view, Oracle keeps going where } >>PostgreSQL does not. Given that both are running over the same network, } >>the response of these people could well be to simply move everything to } >>Oracle. } >> } >>The question, then, is: what can we PostgreSQL people can do to match } >>this Oracle ability?? } >> } > } >Unless there is more information, nothing. This is the first time I } >have heard of this in my 6 years with PostgreSQL. } > } OK - now I have spoken with you sages, I will indeed go back and see if } these people have any more information. } } Many thanks. } } } } ---------------------------(end of broadcast)--------------------------- } TIP 4: Don't 'kill -9' the postmaster >-- End of excerpt from Bruce Badger
В списке pgsql-interfaces по дате отправления: