Unterschied PostgreSQL unter Windows/Unix

Bei einem DB Test unter windows und Unix (speziell FreeBSD)
habe ich leider einen unerfreulichen Unterschied feststellen müssen.

Der Test ist eine Mischung aus Insert/Select und Delete Statements mit Ve=
rknüpfungen
über mehrere Tabellen.
Die Anzahl der Datensätze wächst dabei in den Tabellen systematisch.
Zum Schluss sind in der größten Tabelle ca. 1/2 Million Einträge.

Unter FreeBSD bleibt die Zeit für eine Testblock (mit den div. Statemen=
ts)
mit zunehmender Tabellengröße ungefähr gleich bzw. ein ganz leichte=
r Anstieg
der Zeit.

Unter Windows jedoch wächst die benötigte Zeit linear mit der Anzahl =
der Einträg :-(

Die statistikinfos belegen aber eine gute Nutzung der Inizes.

Kennt jemand dieses Verhalten und kann ggf. Tips geben?

Danke,

Mike

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Re: Unterschied PostgreSQL unter Windows/Unix

Mike Schubert schrieb:

> Bei einem DB Test unter windows und Unix (speziell FreeBSD)
> habe ich leider einen unerfreulichen Unterschied feststellen müssen.
>=20
> Der Test ist eine Mischung aus Insert/Select und Delete Statements mit =
Verknüpfungen
> über mehrere Tabellen.
> Die Anzahl der Datensätze wächst dabei in den Tabellen systematisch=
..
> Zum Schluss sind in der größten Tabelle ca. 1/2 Million Einträge.
>=20
> Unter FreeBSD bleibt die Zeit für eine Testblock (mit den div. Statem=
ents)
> mit zunehmender Tabellengröße ungefähr gleich bzw. ein ganz leich=
ter Anstieg
> der Zeit.
>=20
> Unter Windows jedoch wächst die benötigte Zeit linear mit der Anzah=
l der Einträg :-(
>=20
> Die statistikinfos belegen aber eine gute Nutzung der Inizes.
>=20
> Kennt jemand dieses Verhalten und kann ggf. Tips geben?

Windows ist Scheiße, nimm UNIX ;-)

Mmmh. Der Windows-Port ist sehr neu. Erwarte keine Wunder.



Andreas
--=20
Diese Message wurde erstellt mit freundlicher Unterstützung eines freil=
au-
fenden Pinguins aus artgerechter Freilandhaltung. Er ist garantiert fre=
i
von Micro$oft'schen Viren. (#97922 http://counter.li.org) GPG 7F4584D=
A
Was, Sie wissen nicht, wo Kaufbach ist? Hier: N 51.05082°, E 13.56889°=
;-)

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: Unterschied PostgreSQL unter Windows/Unix

On Wed, Mar 30, 2005 at 05:26:05PM +0200, Kretschmer Andreas wrote:
> Mike Schubert schrieb:
>=20
> Windows ist Scheiße, nimm UNIX ;-)

Mhh, die Aussage hilft nicht, da neben FreeBSD/Linux/Solaris eben
auch Windows sein muss :-|

>=20
> Mmmh. Der Windows-Port ist sehr neu. Erwarte keine Wunder.
>=20

gut, ich habe noch vergessen zu erwähnen, das ein anderer Test, der jed=
och
die Daten nicht so "normalisiert" - sprich etwas redundanter und damit mi=
t
weniger Vergnüpfungen - speichert, zeigt auch unter Windows einen konst=
anten
Zeitverlauf.

Deshalb gehe ich davon aus, dass irgendetwas im zusammenspiel "viele (und=
grosse)
Tabellen + windows" etwas hakt. Ich bin mit meinem Latein am Ende und ohn=
e
Eingrenzung der Ursache ist auch keine Beseitigung möglich :-/

Vielleicht ist ja schon jemand weiter gekommen als ich.

Trotzdem erst einmal Danke, ich hoffe noch auf Ideen :-)

MfG

Mike

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

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

Re: Unterschied PostgreSQL unter Windows/Unix

Schreib am besten auf englisch an -performance oder die win32-liste.
Kreise vorher das Problem auf eine oder mehrere Querys ein. Der
Empfänger muss zum Beheben des Problems das Problem reproduzieren
können. Versuche, mit deiner Mail möglichst nahe an das Ideal
heranzukommen. Das Ideal sind hier ein paar Dateien mit allen nötige=
n
Daten und knappen präzisen Erklärungen, worum es geht und wo di=
e
Ungereimtheit ist.

Markus

В Срд, 30/03/2005 в 12:39 +0200, Mike Schubert =D0=
¿Ð¸ÑˆÐµÑ=82:
> Bei einem DB Test unter windows und Unix (speziell FreeBSD)
> habe ich leider einen unerfreulichen Unterschied feststellen müsse=
n.
>=20
> Der Test ist eine Mischung aus Insert/Select und Delete Statements mit =
Verknüpfungen
> über mehrere Tabellen.
> Die Anzahl der Datensätze wächst dabei in den Tabellen system=
atisch.
> Zum Schluss sind in der größten Tabelle ca. 1/2 Million Eintr=
äge.
>=20
> Unter FreeBSD bleibt die Zeit für eine Testblock (mit den div. Sta=
tements)
> mit zunehmender Tabellengröße ungefähr gleich bzw. ein g=
anz leichter Anstieg
> der Zeit.
>=20
> Unter Windows jedoch wächst die benötigte Zeit linear mit der=
Anzahl der Einträg :-(
>=20
> Die statistikinfos belegen aber eine gute Nutzung der Inizes.
>=20
> Kennt jemand dieses Verhalten und kann ggf. Tips geben?
>=20
> Danke,
>=20
> Mike
>=20
> ---------------------------(end of broadcast)--------------------------=
-
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.or=
g
--=20
Markus Bertheau â˜=AD


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Re: Unterschied PostgreSQL unter Windows/Unix

> Unter Windows jedoch wächst die benötigte Zeit linear mit der Anzahl =
der
> Einträg :-(
Es könnte ein Problem der Speicherverwaltung von Windows zu sein.
> Die statistikinfos belegen aber eine gute Nutzung der Inizes.
Vielleicht hilft es die statisikinfos aufzufrischen (VACUUM?).

Michael

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Re: Unterschied PostgreSQL unter Windows/Unix

On Thu, Mar 31, 2005 at 11:36:21AM +0200, Markus Bertheau ??? wrote:
> Schreib am besten auf englisch an -performance oder die win32-liste.
> Kreise vorher das Problem auf eine oder mehrere Querys ein. Der
> Empfänger muss zum Beheben des Problems das Problem reproduzieren
> können. Versuche, mit deiner Mail möglichst nahe an das Ideal
> heranzukommen. Das Ideal sind hier ein paar Dateien mit allen nötigen
> Daten und knappen präzisen Erklärungen, worum es geht und wo die
> Ungereimtheit ist.

Bei den einzelnen Querys fangen die Probleme an, da ich die nicht genau k=
enne.
Es wird beim Test ein Ontologieframework (namens Jena) genutzt.
Ich kenne nur aus dem API-Studium, dass eine Menge Insert/Select/Delete
Operationen abgesetzt werden.=20

Deshalb kann ich nicht mal eingrenzen, ob alle Statements die gleiche=20
"Verlangsamung" bekommen, oder nur ein bestimmter Teil.

Für mich ist entscheident, wieviel Zeit ich zum Speichern einer Resourc=
e
mit n Properties brauche. Beim Speichern dieser Resource mit den Properti=
es und
den Zusammenhängen wird ide DB ganz schön beackert. Ich komme leider =
aus der=20
MSSQL Ecke, so dass ich bei PostgreSQL nicht weiss, wie ich bestimmte=20
Statements mit deren Ablaufzeit in der Datenbank analysieren kann.
(Kannst du ggf. einen Hinweis geben?)

Anhande der verschiedenen pg_stat* und pg_statio* Views konnte ich schon =
erst einmal
herauslesen, das die Indizes gut genutzt werden.

Vielen Dank für deine Antwort und deinen Hinweis auf die o.g. Listen,

Mike

--=20
interface projects GmbH Tel.: ++49-351-3 18 09 15
Tolkewitzer Str.49 Fax.: ++49-351-3 36 11 87
D-01277 D R E S D E N E-Mail: mike.schubert@interface-projects.de

Ein Unternehmen der interface:business-Gruppe
http://www.interface-projects.de

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

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

Re: Unterschied PostgreSQL unter Windows/Unix

On Thu, Mar 31, 2005 at 01:47:02PM +0200, Michael Koenig wrote:
> > Unter Windows jedoch wächst die benötigte Zeit linear mit der Anz=
ahl der
> > Einträg :-(
> Es könnte ein Problem der Speicherverwaltung von Windows zu sein.

Meine Vermutungen gehen auch in Richtung unterchiedlicher resourcenverwal=
tung
bei Unix und Windows. Nur ist die Frage welcher Punkt ist der entscheiden=
de
und wie kann man das Problem umgehen. (ohne das Os zu wechseln :-)

> > Die statistikinfos belegen aber eine gute Nutzung der Inizes.
> Vielleicht hilft es die statisikinfos aufzufrischen (VACUUM?).
>=20

Jeder Testlauf beginnt mit einer "frischen" DB.

Ich habe auch wärend des Testlaufes schon mit Vacuum hantiert, da ich v=
ermutete,
dass evtl. viele als gelöscht markierte Entries die Geschwindigkeit bee=
influssen -
aber nichts dergleichen.

Danke,

Mike
--=20
interface projects GmbH Tel.: ++49-351-3 18 09 15
Tolkewitzer Str.49 Fax.: ++49-351-3 36 11 87
D-01277 D R E S D E N E-Mail: mike.schubert@interface-projects.de

Ein Unternehmen der interface:business-Gruppe
http://www.interface-projects.de

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Re: Unterschied PostgreSQL unter Windows/Unix

В Чтв, 31/03/2005 в 13:49 +0200, Mike Schubert =D0=
¿Ð¸ÑˆÐµÑ=82:

> Für mich ist entscheident, wieviel Zeit ich zum Speichern einer Re=
source
> mit n Properties brauche. Beim Speichern dieser Resource mit den Proper=
ties und
> den Zusammenhängen wird ide DB ganz schön beackert. Ich komme=
leider aus der=20
> MSSQL Ecke, so dass ich bei PostgreSQL nicht weiss, wie ich bestimmte=20
> Statements mit deren Ablaufzeit in der Datenbank analysieren kann.
> (Kannst du ggf. einen Hinweis geben?)

Wenn du mit psql auf die Datenbank kommst, kannst du mit=20

\timing

Zeitmessung anschalten. Nach allen nach diesem Kommando abgesetzten
Queries wird die Laufzeit ausgegeben. Sehr wichtig sind auch EXPLAIN
(dieses Kommando gibt den Ausführungsplan aus) und EXPLAIN ANALYZE (=
Plan
+ Ausführungszeiten für die einzelnen Schritte). Insbesondere i=
m
Vergleich zu Linux, um die Unterschiede feststellen zu können. Eine
weitere Möglichkeit ist es, in postgresql.conf anzuschalten, daß=
die
Statements und ihre Dauer protokolliert werden. Man kann auch nur
Statements protokollieren, die länger als eine bestimmte Zeit gedaue=
rt
haben.

Markus

--=20
Markus Bertheau â˜=AD


---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend