Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-general by date

Next:From: Nicholas PiperDate: 2001-10-30 13:31:04
Subject: Re: Differential Backups
Previous:From: Johnson, ShaunnDate: 2001-10-30 13:21:41
Subject: Re: psql and HTML

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group