Re: Postgres vr.s Oracle
| От | Gregory Stark |
|---|---|
| Тема | Re: Postgres vr.s Oracle |
| Дата | |
| Msg-id | 877i62qgeo.fsf@oxford.xeocode.com обсуждение исходный текст |
| Ответ на | Re: Postgres vr.s Oracle (Josh Berkus <josh@agliodbs.com>) |
| Список | pgsql-advocacy |
Josh Berkus <josh@agliodbs.com> writes: > Not, on TPC-E on the other hand, Oracle is way ahead of us ... we were like 50% > last I checked, due mostly to the amount of time it takes us to resolve lock > conflicts vs. Oracle. Of course, Microsoft is beating Oracle by 50%, so Oracle > is not the one to match on that benchmark. We've done essentially no benchmark optimization so on any sufficiently complex benchmark there will undoubtedly be some piece that we basically are not handling correctly at all. The degree to which the problem, which is essentially a bug, causes a slowdown isn't really relevant. Whether it's 50% or 100% or more isn't really interesting. On the flip side Microsoft and Oracle spend a lot of effort into optimizing for the cases the benchmarks cover. Oracle beat Microsoft over the head with updateable views for a long time because it basically broke some of the older benchmarks and made them thousands of times faster according to those benchmarks. It doesn't surprise me that Microsoft is doing it to Oracle now. I'm amazed at how many people in this thread claim to have diagnosed performance problems that we've never heard about on-list though. What do you mean "due mostly to the amount of time it takes us to resolve lock conflicts"?!? Are you sure it isn't due to the cycles we spend buffering RI triggers and checking them one-by-one? 8.4 has some microoptimizations in this area but I'm thinking there are some algorithmic improvements we could make for batch updates. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!
В списке pgsql-advocacy по дате отправления: