Die verwendete Postgres-Version ist 9.6 auf Windows Server 64 Bit mit 4 GB Hauptspeicher und 2,4 GHz Xeon CPU
Die gleichen Abfragen mache ich schon mit Oracle-Tabellen, die mit organized Indexes erstellt werden.
Dort dauert genau die selbe Query unter 1 ms.
Genauer: der scan von 15,8 Mio Zeilen mit der Query
select * from switchingtime_170613 where uniqueid = 815012;
Liefert
unter Oracle
2226 Zeilen in 0,17 Sekunden aus.
Unter Postgres dauert die gleiche Abfrage
4,45 Sekunden.
Das wiederum bedeutet, das meine Berechnungen, mit den Daten in den Tabellen
mit Oracle ca. 1,5 Stunden lang dauern
mit Postgres ca. 3 Stunden, teilweise auch sehr viel länger
Oracle sorgt dafür, daß der Organized Index stets optimal auf dem Datenträger gespeichert wird.
Darum gehen dann die Abfragen so schnell.
Bei Postgres soll man angeblich die Tabellen regelmäßig mit analyze, vacuum oder cluster optimieren,
was aber bei einer großen Datenbank sehr lange dauert. Ich habe gelesen, daß Postgres-Benutzer den Durchlauf
von cluster nach 17 Stunden abgebrochen haben.
Cluster hat zudem den enormen Nachteil, daß die Tabelle komplett gelockt wird.
Es soll angeblich eine Extension mit dem Namen pg_repack geben, was auf python basiert.
Dieses Werkzeug soll angeblich mit minimalen Locks auskommen. Aber erstens ist die Installation
unter Windows nicht so reibungslos zu machen und zweitens hat mein Chef damit ein Vertrauensproblem.
Auch weiß ich nicht, wie gut dieses Werkzeug tatsächlich ist.
Am liebsten wäre es mir, wenn Postgres von Anfang an mit eigenen Werkzeugen mit großen Datenmengen gut umgehen könnte.
Nochmal ein Versuch von explain analyze:
QA3DB=> explain analyze select * from switchingtime_170613 where uniqueid = 1001;
QUERY PLAN
Bitmap Heap Scan on switchingtime_170613 (cost=41.34…6131.78 rows=1649 width=44) (actual time=19.040…3478.983 rows=2038 loops=1)
Recheck Cond: (uniqueid = 1001)
Heap Blocks: exact=705
-> Bitmap Index Scan on pk_switchingtime_170613 (cost=0.00…40.93 rows=1649 width=0) (actual time=11.274…11.274 rows=2038 loops=1)
Index Cond: (uniqueid = 1001)
Planning time: 1.946 ms
Execution time: 3482.512 ms
(7 Zeilen)
Optimal wäre eine Execution time von unter 1 ms so wie in Oracle