Re: [HACKERS] Serious performance problem

From: Jean-Michel POURE <jm(dot)poure(at)freesurf(dot)fr>
To: "Tille, Andreas" <TilleA(at)rki(dot)de>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: [HACKERS] Serious performance problem
Date: 2001-10-30 13:28:40
Message-ID: 4.2.0.58.20011030141942.00a38ba0@pop.freesurf.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


>thanks for your kind offer to help!
You are welcome.

>Just to make clear the situation once more: I´ve got hints on the
>general list about how to change my database application to perform
>better by using extra tables and indices. I´m also able to do some
>database programming myself, even if I´m not very experienced. But
>the problem is different: There is an existing database application
>which has absolutely no performance problems on MS SQL server. If
>I just test the simplest query and it takes orders of magnitude more
>than something with the server is wrong.
>Moreover chances are low that for this reason changes in the database
>existing application are accepted. What if the MS-SQL server would
>have performance problems and it comes to tuning of the code there
>and we are at the end of speed optimations at our PostgreSQL server.
>There is a binary administrative decision: Yes or no. If the same
>database application does perform this badly we can *NOT* use PostgreSQL.
>The cost of development would be much higher than a second M$-SQL
>server license.
Have you done tests on MS SQL with xx million rows. How much data are you
going to have in a single database?

>There is a binary technical decission: Yes or no. If there is a
>need for at least one additional table for each query of our application
>to perform in a comparable manner than we are lost because we are
>unable to do that for each new query.
Yes.This is what multi-dimensional databases do.$
This time, we will do it "by hand" in PostgreSQL.
With good naming conventions, this will be clean.

>The reason for the performance lack is also clear: It is the different
>use of indexes in PostgreSQL. This would have the consequence of a
>linear scaling of performance compared to the log(n) scaling when
>using indexes strictly. So chances are high that we will run into
>performance trouble again even if we now could cope with the problems.

Beware PHP native MS SQL driver do not work well.

> > Do you have a Windows desktop?
>No, I havn´t?
> > If so, please install pgAdmin II from http://www.pgadmin.org.
>Sorry, I see no relation to the question.

This is for programming in PL/pgSQL and administrating PostgreSQL .
Without pgAdmin, you will quickly mess-up with objects (tables, views,
triggers).

Best regards,
Jean-Michel POURE

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Nicholas Piper 2001-10-30 13:31:04 Re: Differential Backups
Previous Message Johnson, Shaunn 2001-10-30 13:21:41 Re: psql and HTML