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

In article <u+oejbA9W0g0Ewvo@smooth1.demon.co.uk>, David Williams <djw@smooth1.demon.co.uk> wrote: >In article <yutiut8agvy.fsf@mew.corp.sgi.com>, Pablo Sanchez ><pablo@sgi.com> writes >>>>>>> "Michael" == Michael Segel <Mikey@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.