Re: Informix vs. Sybase vs. Oracle vs. (gasp) MS SQL Server

In article <u+oejbA9W0g0Ewvo_at_smooth1.demon.co.uk>, David Williams <djw_at_smooth1.demon.co.uk> wrote:
>In article <yutiut8agvy.fsf_at_mew.corp.sgi.com>, Pablo Sanchez
><pablo_at_sgi.com> writes
>>>>>>> "Michael" == Michael Segel <Mikey_at_NOSPAM.King.of.MyDomain.NOSPAM.Segel.com
>>> writes:
>>Michael>
>>Michael> Conceputaly the finer the granularity of locks
>>Michael> acheived, the better the application will behave
>>Michael> and the easier it is to implement an OLTP
>>Michael> application.
>>
>>and you ignore the fact that there's added overhead with row
>>level locking. When you consider the *whole* picture, you
>>soon see that it doesn't make a difference.
>>
>>Michael> Now, as to TPC benchmarks, why don't you print the configurations used.
>>:-)
>>
>>They're lengthy... but I've told people where to look for
>>them (and I'll do it again: www.tpc.org). But if you
>>inisist on the other number, for the Sybase number that
>>beats Informix, we have $94.18/tpmC vs $139.04/tpmC for
>>Informix. It's cheaper to use Sybase and you get 60+%
>>better performance.
>>
>>Michael> (Yes Virginia, I have done benchmarking and I know
>>Michael> that everyone cheats:-)
>>
>>There are FDR's for the TPC-C's. Tell me on these two
>>benches where people "cheated".
>>
>>I grant you that TPC-C's aren't true real world but it's the
>>best that we have for a normalized application. Not
>>something silly like "well my hotel reservation system ran
>>great using product X and sucked on product Y" All that
>>proves is that someone may not have known how to write an
>>application. Big deal.
>>
>>Michael> He's saying that there are other things that Sybase
>>Michael> does well, inspite of not havingrow level
>>Michael> locking. Would you care to elaborate. It was the
>>Michael> same point I was trying to make. Only you thought
>>Michael> to say SNIP! :-)
>>
>>The issue has never been whether Sybase does row level or
>>page level locking. I'm just talking about the issue
>>itself on row level vs page level locking. You and he keep
>>wanting to try and drag Sybase into this whole thread. I
>>could care less about Sybase at this point. I only bring in
>>Sybase because it's the only RDBMS at this point in time
>>doing page level locking. And it's proven with the -C's
>
> Psst! Wrong. Informix supports page and row level locking!
> Default is page level and you do
>
> alter table xx lock mode (row) to change it
>
> [or alter table xx lock mode (page) to change it back].
>
> If Informix can do either then performance comparision with
> Sybase mean nothing, if page was faster Informix would use
> page level locking in TPC tests!!
>

Ahh, but they have fallen into the same trap as everyone else thinking that row-level locking is the only way to go (it has to be faster, right:)). Informix used to use row-level locking a lot in their TPC-C disclosures. I'm not sure if they do this so much any longer given they can partition tables and indexes.

Anyway, all the "Sybase" comparison was meant to do was to show a page-level locking app doing very well on an OLTP application. It was not really meant to say Informix was losing a bunch of performance because they use row-level locking (they will lose some, but not 60%).

--Chris
My own views. Received on Tue Dec 09 1997 - 00:00:00 CET