Re: Serious performance problem - Mailing list pgsql-hackers

> My problem is to convince my colleague.  I�m afraid that he would consider
> those optimizing stuff as "tricks" to work around constraints of the
> database server.  He might argue that if it comes to the point that also
> MS SQL server needs some speed improvement and he has to do the same
> performance tuning things MS SQL does outperform PostgreSQL again and we
> are at the end with our wisdom.  I repeat:  I for myself see the strength
> of OpenSource (Horst, you know me ;-) ) and I would really love to use
> PostgreSQL.  But how to prove those arguing wrong? *This* is my problem.
> We have to do a design decision.  My colleague is a mathematician who
> has prefered MS SQL server some years ago over Oracle and had certain
> reasons for it based on estimations of our needs.  He had no problems
> with UNIX or something else and he theoretically is on my side that OpenSource
> is the better way and would accept it if it would give the same results
> as his stuff.
> But he had never had some performance problems with his databases and
> knows people who claim to fill Zillions of Megabytes of MS SQL server.
> So he doubt on the quality of PostgreSQL server if it has problems in
> the first run.  I have to admit that his point of view is easy to
> understand.  I would have to prove (!) that we wouldn�t have trouble
> with bigger databases and that those things are no "dirty workarounds"
> of a weak server.
>
> > And, don't forget that the only way MS SQL can achieve the better performance
> > here is through mercilessly hogging ressources. In a complex database
> > environment with even larger tables, the performance gain in MS SQL would be
> > minimal (my guess).
> Unfortunately it is not enough to guess.  He has enough experiences that
> I knows that the MS SQL server is fit for the task he wants to solve.  If
> I tell him: "*Perhaps* you could run into trouble.", he would just laugh
> about me because I�m in trouble *now* and can�t prove that I won�t be
> again.

The only way to know for certain is to try both at various sizes to see.
Getting numbers for one type of query on one size database tells very
little.  Load a test set that's 100, 1000, whatever times the current size
and see what happens.  ISTM anything short of this is fairly meaningless.
What point does the other person expect to run into problems, how would
he solve them, how does postgres run at that point with and without
special optimization.

It's perfectly possible that for the particular queries and load you're
running that MSSQL will be better, there's nothing
wrong with that.  Conversely, it's entirely possible that one could find
workloads that postgres is better at.