>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
