Um die Seitengenerierung für Seiten zu beschleunigen, die auf großen Postgresammlungen basieren, werden die Abfrageergebnisse in Memcache zwischengespeichert. Bei unveränderbaren Sammlungen, die sehr groß sind oder auf die nur selten zugegriffen wird, frage ich mich, ob das Speichern von Server-seitigen Cursorn in Postgres eine praktikable alternative Zwischenspeicherungsstrategie wäre.
Der Grundgedanke ist, dass nach der Bereitstellung einer Seite in der Mitte einer Sammlung "next" und "prev" eher Links verwendet werden als eine zufällige Abfrage irgendwo anders in der Sammlung. Könnte ich einen Cursor "WITH HOLD" in der Nachbarschaft haben, um die (scheinbar unvermeidlichen) großen Startkosten der Abfrage zu vermeiden?
Ich wundere mich über den Ressourcenverbrauch auf dem Server. Wenn die Sammlung unveränderlich ist, sollte das Speichern des Cursors nicht sehr viele Ressourcen benötigen, aber ich frage mich, wie optimiertes Postgres in dieser Hinsicht ist. Irgendwelche Links zu weiterer Dokumentation würden geschätzt.
Sie werden eine Menge Probleme bekommen.
Kurz gesagt: Tu es nicht. Wie wäre es mit der Vorberechnung der nächsten / vorherigen Seite im Hintergrund und dem Speichern in memcached?
Eine gute Antwort darauf wurde zuvor gemacht Beste Möglichkeit, die fortlaufende Liste mit PostgreSQL im Web abzurufen
Die Fragen sind ähnlich, im Wesentlichen speichern Sie eine Liste von PKs auf dem Server mit einem Paginierungs-Token und einem Ablaufdatum.
Tags und Links postgresql