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!