Re: Performance question (stripped down the problem)

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: "Tille, Andreas" <TilleA(at)rki(dot)de>
Cc: PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Performance question (stripped down the problem)
Date: 2001-09-19 12:25:22
Message-ID: Pine.LNX.4.30.0109191411110.1053-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tille, Andreas writes:

> 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;

> (which should just measure the time needed for this task). It took my
> E250 (2x400MHz, 2GB) server 20 seconds and this is definitely much to
> long for our application.

I loaded this into 7.2 development sources and it ran 35 seconds
wall-clock time on a much smaller machine. After I ran what in 7.1 would
be VACUUM ANALYZE it took about 22 seconds. The difference was that it
was using the index on hauptdaten_fall.istaktuell when it shouldn't.
(Try EXPLAIN to see what it does in your case. If it's still using the
index you might want to force enable_indexscan = off.)

I also got a minuscule speed-up by replacing the Count(Hauptdaten_Fall.ID)
with Count(*), which acts differently with respect to nulls, so it depends
whether you want to use it.

Besides that, I don't see anything blatantly obvious to speed this up.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://funkturm.homeip.net/~peter

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tille, Andreas 2001-09-19 13:32:11 Re: Performance question (stripped down the problem)
Previous Message Mark Muffett 2001-09-19 12:04:26 Booleans