Es gibt Fälle, in denen PostgreSQL unter Windows aufgrund von Kompromissen bei der Portierung einen zusätzlichen Overhead im Vergleich zu anderen Lösungen verursacht.
Beispielsweise verwendet PostgreSQL einen Prozess pro Verbindung, MySQL verwendet einen Thread. Unter Unix ist dies normalerweise kein merklicher Leistungsunterschied, aber unter Windows ist das Erstellen neuer Prozesse sehr teuer (aufgrund des fehlenden Systemaufrufs fork()). Aus diesem Grund ist es viel, dauerhafte Verbindungen oder einen Verbindungspooler zu verwenden wichtiger unter Windows bei Verwendung von PostgreSQL.
Ein weiteres Problem, das ich gesehen habe, ist, dass frühes PostgreSQL unter Windows standardmäßig sicherstellt, dass seine Schreibvorgänge durch den Schreibcache gehen – selbst wenn es batteriegepuffert ist. AFAIK, MySQL tut dies nicht und es wird die Schreibleistung stark beeinträchtigen. Nun, dies ist tatsächlich erforderlich, wenn Sie eine nicht sichere Hardware haben, z. B. ein billiges Laufwerk. Wenn Sie jedoch einen batteriegestützten Schreibcache haben, möchten Sie diesen in reguläres fsync ändern. Moderne Versionen von PostgreSQL (sicherlich 8.3) verwenden stattdessen standardmäßig open_datasync, was diesen Unterschied beseitigen sollte.
Sie erwähnen auch nichts darüber, wie Sie die Konfiguration der Datenbank optimiert haben. Standardmäßig ist die mit PostgreSQL gelieferte Konfigurationsdatei sehr konservativ. Wenn Sie dort nichts geändert haben, müssen Sie sich das unbedingt ansehen. Im PostgreSQL-Wiki sind einige Tuning-Ratschläge verfügbar .
Um mehr Details zu geben, müssen Sie viel mehr Details darüber angeben, was genau langsam läuft und wie Sie Ihre Datenbank optimiert haben. Ich würde eine E-Mail an die pgsql-general-Mailingliste vorschlagen.
