Re: [HACKERS] Serious performance problem
От | Jean-Michel POURE |
---|---|
Тема | Re: [HACKERS] Serious performance problem |
Дата | |
Msg-id | 4.2.0.58.20011030141942.00a38ba0@pop.freesurf.fr обсуждение исходный текст |
Ответ на | Re: [HACKERS] Serious performance problem (Jean-Michel POURE <jm.poure@freesurf.fr>) |
Ответы |
Re: [HACKERS] Serious performance problem
|
Список | 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
В списке pgsql-general по дате отправления: