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

From Karsten Hilbert
Subject Re: [pgsql-de-allgemein] Query SELECT * sehr langsam
Date
Msg-id 20051207175118.GU5968@merkur.hilbert.loc
Whole thread Raw
In response to Re: [pgsql-de-allgemein] Query SELECT * sehr langsam  ("Axel Loder" <axellod@gmx.net>)
List pgsql-general
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

pgsql-general by date:

Previous
From: Volkan YAZICI
Date:
Subject: Re: Problem: libpq, network traffic, memory usage
Next
From: Alexander Scholz
Date:
Subject: Re: Problem: libpq, network traffic, memory usage