PostgreSQL 10.1

Hier dreht es sich um den PostGre Server

Moderator: Moderatoren

Antworten
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

PostgreSQL 10.1

Beitrag von ramses »

Hi

ich habe ein Upgrade auf die neue Postgre Version 10.1 gemacht. Die Performance ist markant besser geworden.
Deshalb plane ich auch die Produktiven Systeme zu upgraden.

Hat jemand negative Erfahrungen mit der 10.1 Version gemacht? (FreeBSD/ZFS nicht Windows)


Gruss Carlo
Valar Morghulis

Gruss Carlo
dtreplin
Rookie
Rookie
Beiträge: 5
Registriert: Sa, 27. Nov 2010 15:23

Re: PostgreSQL 10.1

Beitrag von dtreplin »

Hallo Carlo,

ich habe keinen Vergleich zur Vorgängerversion, aber ich versuche gerade eine Migration einer sehr umfangreichen Inhouse-Anwendung von DBFCDX zu Postgres. Upsize etc. hat nach einigen Anläufen funktioniert. Als echt Datenbank (und nicht PGDBE-spezifisdches) Problem kämpfe ich gerade mit dem Query-Optimizer von Postgres bei ganz banalen SEEKs und SKIPs. De OPtimizer hat wohl extreme Probleme mit Range Conditions, also größer als und kleiner als.

Die Datenbank ("stamm") hat ca 250.000 Einträge (Firmenadressen)
Ich habe das SQL-Log eingeschaltet, um zu sehen, was passiert.

Die Datenbank "stamm" hat u.a. ein feld "firma1" mit dem Firmennamen. Kardinalität für den Index also bestens. Der Index ist auch vorhanden und kann von Postgres auch benutzt werden. Es ist keine Nutzerfunktion im Index.

Aus einem dbseek(firma), aber auch aus jedem folgenden skip(1) macht die PGDBE (unter vielem anderen) folgendes SQL-Statement:

SELECT * FROM stamm WHERE __order_stamm_firma1>= 'HIGHTEXT' ORDER BY __order_stamm_lfnr LIMIT 100

Das Problem: die Query dauert etwa 500 ms.
Ein Explain zeigt, dass Postgres einen Table Scan macht, anstatt den Index zu benutzen:

EXPLAIN ANALYZE SELECT * FROM stamm WHERE __order_stamm_firma1 >= 'HIGHTEXT' ORDER BY __order_stamm_firma1 LIMIT 100;

"Limit (cost=60318.08..60318.33 rows=100 width=1411) (actual time=649.624..649.637 rows=100 loops=1)"
" -> Sort (cost=60318.08..60709.02 rows=156375 width=1411) (actual time=649.623..649.626 rows=100 loops=1)"
" Sort Key: __order_stamm_lfnr"
" Sort Method: top-N heapsort Memory: 301kB"
" -> Seq Scan on stamm (cost=0.00..54341.54 rows=156375 width=1411) (actual time=0.028..515.939 rows=156385 loops=1)"
" Filter: (__order_stamm_firma1 >= 'HIGHTEXT'::bpchar)"
" Rows Removed by Filter: 99338"
"Planning time: 1.275 ms"
"Execution time: 649.787 ms"

Zum Vergleich: Ein Like auf "HIGHETXT%", ordentlich optimiert über den Index, der auch 100 Datensätze abliefert:

EXPLAIN ANALYZE SELECT * FROM stamm WHERE __order_stamm_firma1 LIKE 'HIGH%' ORDER BY __order_stamm_lfnr LIMIT 100;

"Limit (cost=405.56..405.81 rows=100 width=1411) (actual time=0.501..0.508 rows=100 loops=1)"
" -> Sort (cost=405.56..405.88 rows=128 width=1411) (actual time=0.500..0.503 rows=100 loops=1)"
" Sort Key: __order_stamm_lfnr"
" Sort Method: quicksort Memory: 260kB"
" -> Bitmap Heap Scan on stamm (cost=5.47..401.08 rows=128 width=1411) (actual time=0.046..0.189 rows=117 loops=1)"
" Filter: (__order_stamm_firma1 ~~ 'HIGH%'::text)"
" Heap Blocks: exact=111"
" -> Bitmap Index Scan on stamm__order_stamm_firma1 (cost=0.00..5.44 rows=102 width=0) (actual time=0.029..0.029 rows=117 loops=1)"
" Index Cond: ((__order_stamm_firma1 ~>=~ 'HIGH'::bpchar) AND (__order_stamm_firma1 ~<~ 'HIGI'::bpchar))"
"Planning time: 5.861 ms"
"Execution time: 0.580 ms"

Bei 500 ms statt erwarteter 1-2 ms für einen SEEK() ist die gesamte Anwendung also leider völlig unbrauchbar.
Das "LIMIT 100" verstehe ich auch überhaupt nicht, hat aber nix mit der Postgres-Version zu tun.

Ich hatte gehofft, dass diese Notiz aus den release notes de 10.1 das Problem vielleicht beheben würde, tat sie aber nicht:
Correctly detect hashability of range data types (Tom Lane)
Noch eine Anmerkung: Das Test-System ins Windows, das Ziel-System für den Server ist Linux. Ich gehe aber davon aus, dass an dieser Stelle das Betriebssystem keinen Unterschied macht.
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: PostgreSQL 10.1

Beitrag von ramses »

Hallo dtreplin

das "Limit 100" kann ich dir erklähren, dies bedeutet das Postgres die ersten 100 Ergebnisse (Tuples) z.B. von select ... bereitstellt.

Leider ist die Postgres PGDBE von Alaska für grössere Dateien mit über ca 100 Datensätzen oder so unbenutzbar. So wie du es beschreibst.
Auch auf die upsize Funktion solltest du verzichten. Diese legt Felder und Funktionen an die das ganze verlangsamen wenn Sie überhaupt funktioniert. (Beim wechsel auf Postgres 9 wurden einige Regeln verändert die upsize nicht beherscht. Stand Frühling)


Momentan ist einzige Weg die Datenbanken "Selbst" anzulegen bezw. "Natives Postgres" zu verwenden und dir zuerst einige Klassen und Tools für den Datenzugriff und das erstellen von Datenbanken selbst zu schreiben.
Klar dies gibt einige Arbeit. Du wirst aber mit einer Performance belohnt die du jetzt nicht für möglich hältst.


Du findest hier im Forum einige Beiträge zu diesem Thema.

Gruss Carlo
Valar Morghulis

Gruss Carlo
dtreplin
Rookie
Rookie
Beiträge: 5
Registriert: Sa, 27. Nov 2010 15:23

Re: PostgreSQL 10.1

Beitrag von dtreplin »

Hallo Carlo,

ich habe das Problem gerade gelöst:

Der Index, den der Upsize anlegt, wird mit folgendem Befehl erzeugt:

CREATE INDEX stamm__order_stamm_firma1
ON public.stamm
USING btree
(__order_stamm_firma1 COLLATE pg_catalog."default" bpchar_pattern_ops);

Eine Google-Suche nach bpchar_pattern_ops führte mich dann auf diese Seite:

https://www.postgresql.org/docs/current ... class.html

Hier heisst es im 3. Absatz:

Note that you should also create an index with the default operator class if you want queries involving ordinary <, <=, >, or >= comparisons to use an index. Such queries cannot use the xxx_pattern_ops operator classes. (Ordinary equality comparisons can use these operator classes, however.) It is possible to create multiple indexes on the same column with different operator classes. If you do use the C locale, you do not need the xxx_pattern_ops operator classes, because an index with the default operator class is usable for pattern-matching queries in the C locale.

Also einen neuen Index angelget:

CREATE INDEX stamm_order_stamm_firma1
ON public.stamm
USING btree
(__order_stamm_firma1 COLLATE pg_catalog."default");

und siehe da, execution time faktor 1/1000 ....:

explain analyze select __order_stamm_firma1 from stamm where __order_stamm_firma1 >= 'HIGHEXT' order by __order_stamm_firma1 limit 100;

"Limit (cost=0.42..2.22 rows=100 width=42) (actual time=0.660..0.737 rows=100 loops=1)"
" -> Index Only Scan using stamm_order_stamm_firma1 on stamm (cost=0.42..2814.02 rows=156477 width=42) (actual time=0.658..0.732 rows=100 loops=1)"
" Index Cond: (__order_stamm_firma1 >= 'HIGHEXT'::bpchar)"
" Heap Fetches: 0"
"Planning time: 2.446 ms"
"Execution time: 0.770 ms"

Oh mann ...

Daniel
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: PostgreSQL 10.1

Beitrag von AUGE_OHR »

hi,
dtreplin hat geschrieben: Mo, 13. Nov 2017 17:54ich habe das Problem gerade gelöst:
das hört sich doch schon mal gut an.

wie Ramses schon sagte ist PGDBE von Alaska "unbrauchbar" für grössere Datenmengen.
das Konzept mit den "internen Felder" sorgt für einen massiven Overhead was das ganze nicht schneller macht.

richtigt ist es, wie du es machst, mittels PgAdmin.EXE, in der Workbench die "richtigen" Ausdrücke zu entwickeln.
dazu gehören auch "richtige" Indexe und nicht was Alaska mit PgDBE "zusammen-bastelt"

grob gesagt : ohne SQL Kenntnisse kommt man bei PostgreSQL nicht sehr weit.

deshalb stellt sich die Frage ob man überhaupt PgDBE benutzen sollte oder gleich alles selbst "native" macht.
bei "native" hat man den Vorteil unabhängig von Alaska zu sein ... und man ist selbst verantwortlich für seinen Code.

siehe dir doch mal den Thread viewtopic.php?f=24&t=8564 an.
dort wird beschrieben wie man sich selbst eine CLASS zum Zugriff auf PostgreSQL herstellt.
gruss by OHR
Jimmy
dtreplin
Rookie
Rookie
Beiträge: 5
Registriert: Sa, 27. Nov 2010 15:23

Re: PostgreSQL 10.1

Beitrag von dtreplin »

Naja, 170.000 Zeilen Code mal eben native SQL machen ist in diesem Fall keine Option, vor allem da diese strukturell nah am Datenbankmodell orientiert sind. Abgesehen von einigen irren Bugs (skip(1) nach dbseek() verhält sich wie dbgotop(), wenn man nicht davor ein dbgoto(recno()) macht und ahnliches) scheint das ja sonst zu funktionieren.

Der Overhead der PGDBE ist im übrigen gar nicht so groß. Dass die ab gewissen Datenmengen schlapp macht ist völlig klar, wenn die zentralen Querys des DBF-Modells DBF, also SEEK und SKIP, unter Postgres immer Table Scans machen. Das schöne ist: Man kann das Serverseitig einfach durch neugenerieren der Inddizes ohne " bpchar_pattern_ops" reparieren.

Daniel
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: PostgreSQL 10.1

Beitrag von ramses »

Hallo Daniel

sicher gibt natives Postgres einiges an Arbeit. Aber der einfache der Austausch der CDXDBF gegen die PGDBE ohne kompletten umfangreichen Test der APP wird dir vorallem eines bringen: Sehr viel Arbeit und Aerger mit den Kunden ..... Die PGDBE ist von der Idee her eine gute Sache, leider funktioniert Sie nicht richtig ist viel zu langsam und ist nicht fertig .... und mit grossen Datenbeständen unbenutzbar.

Aufgrund der Technischen Entwicklung bleibt über kurz oder lang nur noch der Einsatz von PostgresSQL oder vielleicht SQLExpress. Damit die klassischen DBE's funktionieren sind zu viele Einstellungen in den Netzwerken nötig die bereits jetzt von vielen System-Admins abgelehnt werden. Auch der neuste ADS hat eine neue Strategie und lässt sich z.T. in bestimmter Umgebung schon gar nicht mehr installieren und nicht mehr verwenden. (Leider)

Ich selbst sehe die Zukunft nur noch bei Web-Apps die im Browser Geräteunabhängig arbeiten. Die Zeit der klassischen EXE mit GUI Oberfläche ist vorbei. Bei der überarbeitung kann dann auch gleich auf natives Postgres gewechselt werden.

Gruss Carlo
Valar Morghulis

Gruss Carlo
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: PostgreSQL 10.1

Beitrag von georg »

Guten Morgen,


die Anzahl der Code-Zeilen ist kein Indikator, die Zukunftssicherheit schon.

Ich arbeite mit Hector Peroza's MySQL-Wrapper und in auch in vielen Programmen durch diese Arbeit durchgegangen, ich habe die Zeilen nie gezählt.

Beim ersten Programm habe ich eine DBF-Datei nach der anderen ersetzt, also nicht alles auf einmal umgebaut. Das war in richtig guter Code-Review, für den man sich sonst nie die Zeit nimmt.

Dazu kommt, dass man auch den Programm-Code vereinfachen kann, da man viele Schleifen, die komplex abgefragt werden, durch die Verlagerung in eine entsprechende SELECT-Anweisung deutlich vereinfachen kann. Von Gruppenwechseln will ich hier jetzt gar nicht reden.

Der Weg lohnt sich, auch wenn der Aufwand anfänglich recht gross aussieht.
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: PostgreSQL 10.1

Beitrag von ramses »

Hallo

Ich hatte den Mut in der Nach auf gestern eine grössere App von 9.6 auf 10.1 zu upgraden. Es sind keinerlei Probleme aufgetreten. Lief den ganzen Tage einwandfrei.

Gruss Carlo
Valar Morghulis

Gruss Carlo
Antworten