Query SELECT * sehr langsam

Started by Axel Loderover 20 years ago13 messagesgeneral

axellod@gmx.net

over 20 years ago

Hallo,

POstgreSQL 8.1 ist auf einem Windows 2003 Server (SP 1) installiert. Die
Datenbank besteht aus 26 Tabellen. In einer Tabelle (Adressen) sind ca
300000 Datensï¿½tze vorhanden. Wenn vom pgAdmin, lokal auf dem Server, die
Abfrage "SELECT * FROM "ADRESSEN" gestartet dauert die Ausfï¿½hrung sehr
lange. Bis die ersten 100 Datensï¿½tze angezeigt werden dauert es 83.218 ms.

Welche Mï¿½glichkeiten gibt es hier um den Zugriff zu optimieren?

Serverdaten:
Arbeitsspeicher: 1 GB
P 4 , 3.00 Ghz

Wichtigste Einstellungen in PostgreSQL 8.1:
max_connections 100
shared_buffers 10000
work_mem 10240
auto_vacuum on

Abfrage:
-- Abfrage ausfï¿½hren:
SELECT * FROM "ADRESSEN";

Gesamtlaufzeit der Abfrage: 83218 ms.
Benï¿½tigte Zeit zum Holen der Daten:89828 ms.
302973 Zeilen geholt.

Freue mich ï¿½ber jeden Tipp,
danke,
Axel Loder

--
Highspeed-Freiheit. Bei GMX supergï¿½nstig, z.B. GMX DSL_Cityflat,
DSL-Flatrate fï¿½r nur 4,99 Euro/Monat* http://www.gmx.net/de/go/dsl

Harald Fuchs

hf0923x@protecting.net

over 20 years ago

In reply to: Axel Loder (#1)

Re: Query SELECT * sehr langsam

In article <2013.1133884053@www49.gmx.net>,
"Axel Loder" <axellod@gmx.net> writes:

Hallo,
POstgreSQL 8.1 ist auf einem Windows 2003 Server (SP 1) installiert.

(Ich verhneif mir mal eine Bemerkung über dieses Betrübsystem.)

Die
Datenbank besteht aus 26 Tabellen. In einer Tabelle (Adressen) sind ca
300000 Datensätze vorhanden. Wenn vom pgAdmin, lokal auf dem Server, die
Abfrage "SELECT * FROM "ADRESSEN" gestartet dauert die Ausführung sehr
lange. Bis die ersten 100 Datensätze angezeigt werden dauert es 83.218 ms.

Welche Möglichkeiten gibt es hier um den Zugriff zu optimieren?

Die Übetragung von 300000 möglicherweise längeren Zeilen dauert eben
seine Zeit, aber Dir scheint es eher um die Zeit zwischen dem Absetzen
der Query und dem Eintreffen der ersten Ergebniszeile zu gehen - und
die läßt sich durch Verwenden eines Cursors reduzieren.

A. Kretschmer

andreas.kretschmer@schollglas.com

over 20 years ago

In reply to: Axel Loder (#1)

Re: Query SELECT * sehr langsam

am 06.12.2005, um 16:47:33 +0100 mailte Axel Loder folgendes:

Hallo,

POstgreSQL 8.1 ist auf einem Windows 2003 Server (SP 1) installiert. Die
Datenbank besteht aus 26 Tabellen. In einer Tabelle (Adressen) sind ca
300000 Datensï¿½tze vorhanden. Wenn vom pgAdmin, lokal auf dem Server, die
Abfrage "SELECT * FROM "ADRESSEN" gestartet dauert die Ausfï¿½hrung sehr
lange. Bis die ersten 100 Datensï¿½tze angezeigt werden dauert es 83.218 ms.

Bin mir grad nicht sicher, ob Du nun (rund) 83 ms oder 83 Sekunden
meinst...

Welche Mï¿½glichkeiten gibt es hier um den Zugriff zu optimieren?

Nenne mir doch mal bitte eine sinnvolle Anwendung, die das braucht.
Also, daï¿½ der Client _ALLE_ Tupel abfragt. Bei Deinem Szenario addieren
sich die Zeiten von

- ausfï¿½hren der Query
- ï¿½bertragen der Daten zum Client
(auch wenn es dieselbe Kiste ist, so ist dennoch der ganze Krempel
via Socket oder localhost zu ï¿½bertragen)
- Empfang, Aufgereitung und Darstellung im Client

Zwischen der DB und dem Client findet dabei einiges an Prozesswechseln
statt.

Mach einfach mal folgendes:

explain analyse SELECT * FROM ADRESSEN;

und schau, wie lange das braucht. Aber nicht von einem Klicki-Bunti-Tool
aus, sonderm vom CLI (Command Line Interace) psql aus. Das, was Du dort
als Zeit siehst, ist die reine PG-Zeit, und diese wird wahrscheinlich um
einiges geringer als Deine genannte Zeit sein.

Davon abgesehen, traue ich Windows eh nicht zu, als Host fï¿½r eine
(performante) Datenbank zu dienen...

Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47212, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=== Schollglas Unternehmensgruppe ===

W. Haslbeck

spam.langweilt@gmx.de

over 20 years ago

In reply to: A. Kretschmer (#3)

Winbashing

Hallo,

[sorry, etwas OT, aber das muss jetzt einfach sein]

Am Dienstag 06 Dezember 2005 16:34 schrieb A. Kretschmer:

Davon abgesehen, traue ich Windows eh nicht zu, als Host für eine
(performante) Datenbank zu dienen...

Kurz:
Andreas, könntest du dein ständiges Windows-Bashing hier bitte sein lassen.

etwas länger:
Versteh' mich nicht falsch: Ich bin ja auch der Meinung daß PostgreSQL auf
einem unixoiden OS "runder" läuft, immerhin ist es in einer solchen Umgebung
geboren und lange Jahre aufgewachsen. Ausserdem bin ich auch davon überzeugt,
daß Linux (seit Jahren, nicht erst seit gestern) eine sehr solide Basis für
kleinere bis mittlere Applikations- und DB-Server darstellt.

ABER ich finde auch, dass der Weg den PG seit 8.0 mit dem nativen Win32 Port
geht, gut, richtig und wichtig ist. Es gibt mehr da draussen als Linux, *BSD
und Solaris. ($ man Tellerrand)

Wenn sich nun jemand mit einem konkreten Problem mit PostgreSQL unter Win32 an
diese (oder die andere deutschsprachige PostgreSQL-) Liste wendet, erwartet
er Hilfe. Ein "Nimm doch Linux, das rockt" hilft niemanden und das will er
auch bestimmt als allerletztes hören.

Es gibt Projekte, da kann man sich sein Target-OS nicht aussuchen. Ansonsten
nimmt man halt was am besten passt und/oder was einem besser liegt. Bei dir,
Andreas ist das wohl Linux (bei mir übrigens auch), aber bitte schreib' doch
niemanden vor, welches OS er zu verwenden hat.

nur meine 0.02 eurocent,
Walter

A. Kretschmer

andreas.kretschmer@schollglas.com

over 20 years ago

In reply to: W. Haslbeck (#4)

Re: Winbashing

am 06.12.2005, um 21:04:34 +0000 mailte W. Haslbeck folgendes:

Hallo,

[sorry, etwas OT, aber das muss jetzt einfach sein]

Am Dienstag 06 Dezember 2005 16:34 schrieb A. Kretschmer:

Davon abgesehen, traue ich Windows eh nicht zu, als Host fï¿½r eine
(performante) Datenbank zu dienen...

Kurz:
Andreas, kï¿½nntest du dein stï¿½ndiges Windows-Bashing hier bitte sein lassen.

Na komm, wir wollen doch mal die Kirche im Dorf lassen, okay?
Das war lediglich eine Bemerkung am Rande, wird ja wohl erlaubt sein.

Was mich eher interessieren wï¿½rde: warum ist bei meinen Postings das
Subject verstï¿½mmelt? Ich war es nicht, im Ausgang war es auch noch in
Ordnung. Mal sehen, was hier passiert...

Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47212, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=== Schollglas Unternehmensgruppe ===

W. Haslbeck

spam.langweilt@gmx.de

over 20 years ago

In reply to: A. Kretschmer (#5)

Re: Winbashing

Hallo!

Na komm, wir wollen doch mal die Kirche im Dorf lassen, okay?
Das war lediglich eine Bemerkung am Rande, wird ja wohl erlaubt sein.

Na klar, aber eine Bemerkung in der Art kommt fast jedesmal von dir, wenn sich
jemand mit einem PostgreSQL/Win32 Problem an diese Liste wendet.

Wiegesagt: Ich bin ja auch kein grosser Freund von Win32, aber die Leute
wollen hier Hilfe und keine Missionierung. Naja, egal. EOT?

Was mich eher interessieren würde: warum ist bei meinen Postings das
Subject verstümmelt? Ich war es nicht, im Ausgang war es auch noch in
Ordnung. Mal sehen, was hier passiert...

Irgend ein MTA auf dem Weg von dir zur Liste (oder gar die
Mailing-Listen-Software?) kommt mit (RFC-konformen) Umlauten im Subject nicht
klar?

Guck mal in den Header:
[...]
From: "A. Kretschmer" <andreas.kretschmer@schollglas.com>
To: pgsql-de-allgemein@postgresql.org
Subject: Re: [pgsql-de-allgemein] =?iso-8859-1?Q?We?=
Message-ID: <20051206100232.GJ18779@webserv.wug-glas.de>
[...]

Walter

Axel Loder

axellod@gmx.net

over 20 years ago

In reply to: A. Kretschmer (#3)

Re: [pgsql-de-allgemein] Query SELECT * sehr langsam

Vielen Dank fï¿½r die Antwort!
Diese Abfrage wird beispielsweise benï¿½tigt um alle Rechnungen anzuzeigen.
Habe jetzt mal das "explain analyse" mit dem psql tool durchgefï¿½hrt und
folgendes kam da raus:
QUERY
PLAN
-----------------------------------------------------------------------------------------------------------------------
Seq Scan on "ADRESSEN" (cost=0.00..14588.75 rows=302975 width=1936)
(actual time=0.052..422.687 rows=302975 loops=1)
Total runtime: 544.169 ms
(2 rows)

Gibt es irgendwelche Schalter (am Server oder an der Datenbank) die man
betï¿½tigen muss um hier einen performancegewinn zu erhalten?
Zum Test habe ich auch mal den perfmon mitlaufen lassen und musste erstaunt
feststellen das schon bei der "Select *" _Abfrage_ sehr viele Datenpakete
ï¿½bermittelt werden!? Gibt es evtl. eine Einstellung das die Datensï¿½tze nicht
schon beim Select * zum Client ï¿½bertragen werden?

Fï¿½r Hinweise und Tips wï¿½re ich sehr Dankbar

Axel Loder

PS: Lohnt sich der Aufwand das ganze mal mit einem Linux server zu testen,
oder wird sich da nicht viel an der Performance ï¿½ndern?

--- Ursprï¿½ngliche Nachricht ---
Von: "A. Kretschmer" <andreas.kretschmer@schollglas.com>
An: pgsql-de-allgemein@postgresql.org
Betreff: Re: [pgsql-de-allgemein] Query SELECT * sehr langsam
Datum: Tue, 6 Dec 2005 17:34:51 +0100
am 06.12.2005, um 16:47:33 +0100 mailte Axel Loder folgendes:

Hallo,

POstgreSQL 8.1 ist auf einem Windows 2003 Server (SP 1) installiert. Die
Datenbank besteht aus 26 Tabellen. In einer Tabelle (Adressen) sind ca
300000 Datensï¿½tze vorhanden. Wenn vom pgAdmin, lokal auf dem Server, die
Abfrage "SELECT * FROM "ADRESSEN" gestartet dauert die Ausfï¿½hrung sehr
lange. Bis die ersten 100 Datensï¿½tze angezeigt werden dauert es 83.218

ms.

Bin mir grad nicht sicher, ob Du nun (rund) 83 ms oder 83 Sekunden
meinst...

Welche Mï¿½glichkeiten gibt es hier um den Zugriff zu optimieren?

Nenne mir doch mal bitte eine sinnvolle Anwendung, die das braucht.
Also, daï¿½ der Client _ALLE_ Tupel abfragt. Bei Deinem Szenario addieren
sich die Zeiten von

- ausfï¿½hren der Query
- ï¿½bertragen der Daten zum Client
(auch wenn es dieselbe Kiste ist, so ist dennoch der ganze Krempel
via Socket oder localhost zu ï¿½bertragen)
- Empfang, Aufgereitung und Darstellung im Client

Zwischen der DB und dem Client findet dabei einiges an Prozesswechseln
statt.

Mach einfach mal folgendes:

explain analyse SELECT * FROM ADRESSEN;

und schau, wie lange das braucht. Aber nicht von einem Klicki-Bunti-Tool
aus, sonderm vom CLI (Command Line Interace) psql aus. Das, was Du dort
als Zeit siehst, ist die reine PG-Zeit, und diese wird wahrscheinlich um
einiges geringer als Deine genannte Zeit sein.

Davon abgesehen, traue ich Windows eh nicht zu, als Host fï¿½r eine
(performante) Datenbank zu dienen...

Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47212, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=== Schollglas Unternehmensgruppe ===

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

--
GMX DSL-Flatrate 1 Jahr kostenlos* + WLAN-Router ab 0,- Euro*
Bis 31.12.2005 einsteigen! Infos unter: http://www.gmx.net/de/go/dsl

Karsten Hilbert

Karsten.Hilbert@gmx.net

over 20 years ago

In reply to: Axel Loder (#7)

Re: [pgsql-de-allgemein] Query SELECT * sehr langsam

On Wed, Dec 07, 2005 at 06:34:25PM +0100, Axel Loder wrote:

Seq Scan on "ADRESSEN" (cost=0.00..14588.75 rows=302975 width=1936)
(actual time=0.052..422.687 rows=302975 loops=1)
Total runtime: 544.169 ms
(2 rows)

Gibt es irgendwelche Schalter (am Server oder an der Datenbank) die man
betï¿½tigen muss um hier einen performancegewinn zu erhalten?

Du solltest sicherstellen, daï¿½ Du die richtigen Indizes fï¿½r
die Tabelle Adressen hast. Dann solltest Du dafï¿½r sorgen,
daï¿½ vacuum oft genug lï¿½uft. Mï¿½glicherweise hat der Query
Planner aber auch recht ? Hast Du wirklich 300 000 Adressen?
Und die brauchst Du wofï¿½r alle auf einmal?

Zum Test habe ich auch mal den perfmon mitlaufen lassen und musste erstaunt
feststellen das schon bei der "Select *" _Abfrage_ sehr viele Datenpakete
ï¿½bermittelt werden!? Gibt es evtl. eine Einstellung das die Datensï¿½tze nicht
schon beim Select * zum Client ï¿½bertragen werden?

Dann mï¿½sstest Du Cursoren benutzen.

PS: Lohnt sich der Aufwand das ganze mal mit einem Linux server zu testen,
oder wird sich da nicht viel an der Performance ï¿½ndern?

Vermutlich doch. Aber Du muï¿½t den Server richtig
konfigurieren (wie auch bei Windows).

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

Alexander Scholz

alexander.scholz1@freenet.de

over 20 years ago

In reply to: Axel Loder (#7)

Re: [pgsql-de-allgemein] Query SELECT * sehr langsam

Hi Axel,

I have exactly the same problem!!! Seems to be a conceptional problem of
libpq (or my usage of it) in my case. Probably in yours, too...

Refer to the other thread with subject "Problem: libpq, network traffic,
memory usage".

HTH,

Alexander.

#10

Tobias Bußmann

e.t.bussmann@ing.twinwave.net

over 20 years ago

In reply to: Axel Loder (#1)

Re: Winbashing

Hallo Andreas,

A. Kretschmer <andreas.kretschmer@schollglas.com> wrote:

Was mich eher interessieren wï¿½rde: warum ist bei meinen Postings das
Subject verstï¿½mmelt? Ich war es nicht, im Ausgang war es auch noch in
Ordnung. Mal sehen, was hier passiert...

Wo wir grade schon dabei sind, wieso verwendest du fast durchgehend folgende
Header-Zeile?

X-MSMail-Priority: High

Ist das eine besonders subtile Form des Winbashings ? ;)
Oder fï¿½gt die auch irgend ein Host ï¿½ber den die Mail lï¿½uft ein? Evt. sogar
der Subject-Verstï¿½mmler?

lg
Tobias

--
"Da Pinguine nicht fliegen kï¿½nnen, kï¿½nnen sie auch nicht abstï¿½rzen" ;)

#11

Andreas Kretschmer

akretschmer@spamfence.net

over 20 years ago

In reply to: Tobias Bußmann (#10)

Re: Winbashing

Tobias Buï¿½mann <e.t.bussmann@ing.twinwave.net> schrieb:

Hallo Andreas,

A. Kretschmer <andreas.kretschmer@schollglas.com> wrote:

Was mich eher interessieren wï¿½rde: warum ist bei meinen Postings das
Subject verstï¿½mmelt? Ich war es nicht, im Ausgang war es auch noch in
Ordnung. Mal sehen, was hier passiert...

Wo wir grade schon dabei sind, wieso verwendest du fast durchgehend folgende
Header-Zeile?

Tue ich das? *unschuldig* *gugg*.

X-MSMail-Priority: High

Fï¿½hlst Du Dich nun bedroht davon? Hint: das sind 23 unschuldige
ASCII-Zeichen (incl. der Leerzeichen). Mehr nicht.

Ist das eine besonders subtile Form des Winbashings ? ;)

Ist das eine Fangfrage?

Oder fï¿½gt die auch irgend ein Host ï¿½ber den die Mail lï¿½uft ein? Evt. sogar
der Subject-Verstï¿½mmler?

Nein.

Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
Kaufbach, Saxony, Germany, Europe. N 51.05082ï¿½, E 13.56889ï¿½

#12

Tobias Bußmann

e.t.bussmann@ing.twinwave.net

over 20 years ago

In reply to: Axel Loder (#1)

Re: Winbashing

Andreas Kretschmer <akretschmer@spamfence.net> wrote:

Wo wir grade schon dabei sind, wieso verwendest du fast durchgehend
folgende Header-Zeile?

Tue ich das? *unschuldig* *gugg*.

danke fï¿½rs abstellen!

X-MSMail-Priority: High

Fï¿½hlst Du Dich nun bedroht davon? Hint: das sind 23 unschuldige
ASCII-Zeichen (incl. der Leerzeichen). Mehr nicht.

Bedroht fï¿½hle ich mich nicht unbedingt, es irritiert mich nur etwas, da ich
den High-Priority-Flag auf den 1. Blick leicht mit dem von mir gesetzten
Highlight-Flag verwechsle. ...Was mich andererseits auch wieder daran
erinnert, auch auf diesem Rechner endlich mal den MS-Mailreader ï¿½ber Bord zu
werfen... (Der Header wird AFAIK nur von denen ausgewertet)

Ist das eine besonders subtile Form des Winbashings ? ;)

Ist das eine Fangfrage?

*g*

Tobias
--
E-Mails sollten Text sein, Text und nur Text. Wenn Gott gewollt hï¿½tte, dass
E-Mail in HTML geschrieben wï¿½rden, endeten Gebete traditionell mit </amen>

#13

A. Kretschmer

andreas.kretschmer@schollglas.com

over 20 years ago

In reply to: Tobias Bußmann (#12)

Re: Winbashing

am 11.12.2005, um 22:48:17 +0100 mailte Tobias Buï¿½mann folgendes:

Andreas Kretschmer <akretschmer@spamfence.net> wrote:

Wo wir grade schon dabei sind, wieso verwendest du fast durchgehend
folgende Header-Zeile?

Tue ich das? *unschuldig* *gugg*.

danke fï¿½rs abstellen!

Nicht wirklich. Ich bin halt nicht ortsgebunden (kannst mich deswegen
gern asozial nennen) und mal hier und mal dort. Klingt lustig, aber ich
kann binnen Sekunden zwischen zu Hause und der Arbeitsstï¿½tte wechseln,
obwohl das ca. 20 km Luftlinie sind ;-)
Tja, und da habe ich unterschiedliche Konfigurationen.

Fï¿½hlst Du Dich nun bedroht davon? Hint: das sind 23 unschuldige
ASCII-Zeichen (incl. der Leerzeichen). Mehr nicht.

Bedroht fï¿½hle ich mich nicht unbedingt, es irritiert mich nur etwas, da ich
den High-Priority-Flag auf den 1. Blick leicht mit dem von mir gesetzten
Highlight-Flag verwechsle. ...Was mich andererseits auch wieder daran
erinnert, auch auf diesem Rechner endlich mal den MS-Mailreader ï¿½ber Bord zu
werfen... (Der Header wird AFAIK nur von denen ausgewertet)

Wenn ich das, was im letzten Satz steht damit bewirke, habe ich
erreicht, was ich erreichen wollte. Danke fï¿½r die Rï¿½ckkopplung ;-)

--
E-Mails sollten Text sein, Text und nur Text. Wenn Gott gewollt hï¿½tte, dass
E-Mail in HTML geschrieben wï¿½rden, endeten Gebete traditionell mit </amen>

Auch wenn ich Signaturen sonst nicht zitiere, tue ich dies hier einmal,
nur um zu sagen, daï¿½ Du da Recht hast.

Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47212, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=== Schollglas Unternehmensgruppe ===