Re: Serious performance problem

Поиск
Список
Период
Сортировка
От Tille, Andreas
Тема Re: Serious performance problem
Дата
Msg-id Pine.LNX.4.33.0110301036340.6117-100000@wr-linux02.rki.ivbb.bund.de
обсуждение исходный текст
Ответ на Re: Serious performance problem  (Jean-Michel POURE <jm.poure@freesurf.fr>)
Список pgsql-hackers
On Mon, 29 Oct 2001, Jean-Michel POURE wrote:

> A possible solution would be:
> CREATE TABLE foo AS
> SELECT Hauptdaten_Fall.MeldeKategorie, Count(Hauptdaten_Fall.ID) AS Anz
> FROM Hauptdaten_Fall WHERE (((Hauptdaten_Fall.IstAktuell)=20))
> GROUP BY Hauptdaten_Fall.MeldeKategorie ORDER BY
> Hauptdaten_Fall.MeldeKategorie;
Sorry, this is NO solution of my problem.

> On 300.000 records, you will get instant results. There are plenty of
> tricks like this one. If you employ them, you will ***never*** reach the
> limits of a double Pentium III computer with U3W discs.
It is really no help if I solve the speed issue of this *very simple,
zeroth order try*.  I repeat a hava a plenty of queries which do much
more complicated stuff than this.  This is just a rude strip down of the
problem fit for debugging/profg issues of the database *server*.  Simple
tricks on a simple example do not help.

> If you need to answer this message, please reply on
> pgsql-general@postgresql.org.
No, because ...

> >I discussed a problem concerning the speed of PostgreSQL compared to
> >MS SQL server heavily on postgres-general list.  The thread starts with
> >message
> >
> >     http://fts.postgresql.org/db/mw/msg.html?mid=1035557
I did so and got the explicit advise of Tom to ask here.

Consider the problem as a benchmark.  I would love to see postgresql
as the winner.

Kind regards
       Andreas.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Philip Warner
Дата:
Сообщение: Re: Odd error in complex query (7.2): Sub-SELECT
Следующее
От: Oleg Bartunov
Дата:
Сообщение: Re: pgsql-committers?