pg_local_cache
Deutsch

Ein Zeilen-Cache
in PostgreSQL.

Lesen Sie Zeilen per Primärschlüssel mit SQL-mget oder RESP. PostgreSQL-Schreibvorgänge invalidieren betroffene Cache-Einträge automatisch.

Lokal ausprobieren Mit SQL vergleichen

Explizite SQL-API · PostgreSQL 14–18 · Open Source

Lokal gemessen · 15. Sep. 2026

839,678Anfragen/s · RESP MGET

3.31× der vorbereiteten SQL-Rate
in diesem Vergleich mit einem Schlüssel

Vorbereitetes SQL
253,790 Anfragen/s
SQL mget
186,296 Anfragen/s
Apple M3 Max · PostgreSQL 16 · Go · 256 Verbindungen.
Aufgewärmter Cache, 1 Schlüssel/Anfrage. Median aus 3 × 5 Sekunden.
SQL mget war hier langsamer; Batch-Ergebnisse weichen ab.
Ergebnisse, Rohdaten und Bedingungen

Ein Aufruf. Zwei Lesepfade.

Ein geeigneter Treffer gibt die gespeicherte Zeile zurück. Ein Fehltreffer oder Bypass liest die Quelltabelle. Ihre gewöhnlichen SELECT-Abfragen behalten ihren bisherigen Pfad.

psql │ Lesevorgänge per Primärschlüssel
-- Attach your table once.
SELECT local_cache.attach_table('public.items');

-- Read rows by primary key.
SELECT local_cache.mget(
  'public.items', ARRAY[42, 7]::bigint[]
);

Node.js-BeispielGo-BeispielRESP-Beispiel

Lesepfad von SQL mget Die Anwendung ruft local_cache.mget in PostgreSQL auf. Nach Eignungs- und Snapshot-Prüfungen gibt ein Cache-Treffer die gespeicherte vollständige Zeile zurück. Ein Fehltreffer oder Bypass liest die Quelltabelle. Beide Pfade geben Zeilen über dieselbe PostgreSQL-Verbindung zurück. PostgreSQL Anwendung local_cache.mget Eignung + Snapshot Treffer Kein Treffer GespeichertZeile QuelleTabelle
Beide Pfade geben serialisierte vollständige Zeilen über dieselbe PostgreSQL-Verbindung zurück. Ein geeigneter Lesevorgang aus der Quelltabelle kann den Cache füllen.
Was ein Treffer im Zeilen-Cache vermeidet
SQL mget

Bis zu 1.024 Schlüssel pro Aufruf. Reihenfolge, Duplikate und NULL-Positionen bleiben erhalten.

Gewöhnliche Schreibvorgänge

INSERT, UPDATE und DELETE invalidieren betroffene Einträge.

Feste Kapazität

Allokieren Sie den gemeinsamen Zeilen-Cache beim Start von PostgreSQL.

Snapshot-Prüfungen

Nicht geeignete Lesevorgänge verwenden die Quelltabelle gemäß den Sichtbarkeitsregeln von PostgreSQL.

Führen Sie denselben Test aus.
Mit jedem Client.

Node.js und Go. Vorbereitetes SQL, SQL mget und RESP MGET.

Ein Runner verwendet dieselben Schlüssel, Batch-Größen, Verbindungszahlen, Dauer und Ergebnisprüfungen. Vergleichen Sie Durchsatz, Latenz sowie CPU und Speicher von PostgreSQL auf Ihrem Rechner.

Vergleich ausführen

Passt das zu Ihrer Arbeitslast?

Sie wählen einen Cache? Vergleichen Sie PostgreSQL-Seiten, Zeilen, materialisierte Sichten und Redis.

Messung lohnt sich

  • Wiederholte vollständige Primärschlüssel-Lesevorgänge.
  • Eine kleine heiße Menge vollständiger Zeilen.
  • READ COMMITTED auf einem beschreibbaren primären Server.
  • Eine Anwendung, die die explizite SQL-API aufrufen kann.

Gewöhnliches SQL beibehalten

  • Joins, Bereiche, Aggregate oder beliebige Abfrageergebnisse.
  • RLS-, partitionierte oder vererbte Tabellen.
  • Eine Datenbank, in der Sie keine native Erweiterung installieren können.
  • Arbeitslasten ohne gemessenen Nutzen.

Lokale Demo starten.

Klonen Sie das Repository und starten Sie einen verworfenen PostgreSQL-Server mit Beispielzeilen. Docker baut die Erweiterung und hält die Demo von Ihren Datenbanken getrennt.

Git und Docker Compose erforderlich
git clone https://github.com/profundium/pg_local_cache.git
cd pg_local_cache
docker compose -f examples/compose.yaml up --build --wait

Beispielzeilen lesen und Cache-Treffer prüfen. Repository bereits geklont? Führen Sie den letzten Befehl aus dessen Stammverzeichnis aus. Für einen vorhandenen Server verwenden Sie den Installationsleitfaden.

Die Installation auf einem vorhandenen Server erfordert einen Neustart von PostgreSQL.

Dokumentation

pg_local_cache lokal ausprobierenFühren Sie pg_local_cache 2.0 in einem verworfenen PostgreSQL aus, lesen Sie Beispielzeilen, prüfen Sie Cache-Treffer, testen Sie Updates und entfernen Sie die Demo, ohne eine bestehende Datenbank zu ändern. Benchmarks des PostgreSQL-CachesGemessene Ergebnisse von pg_local_cache mit Node.js, Go und RESP auf einem Apple M3 Max. Enthält Rechner, PostgreSQL-CPU, Speicher und Methodik. Leitfaden zur PostgreSQL-Caching-EntscheidungWählen Sie PostgreSQL-Seiten-Caching, vorbereitetes SQL, Caching vollständiger Zeilen, materialisierte Sichten oder einen externen Cache nach der Arbeit aus, die vermieden werden soll. Cache-aside mit PostgreSQL und RedisVerwenden Sie PostgreSQL als Quelle der Wahrheit mit einem Redis-Cache-aside-Pfad, verstehen Sie Race Conditions bei veralteten Lesevorgängen und sehen Sie, wo pg_local_cache passt. Batch-Abfragen von PostgreSQL per PrimärschlüsselErsetzen Sie N+1-Abfragen per Primärschlüssel durch eine parametrisierte PostgreSQL-Abfrage, erhalten Sie bei Bedarf Eingabepositionen und vergleichen Sie den expliziten pg_local_cache-mget-Pfad. PostgreSQL-Zeilen-Cache im Vergleich zu shared_buffersVergleichen Sie das PostgreSQL-Seiten-Caching mit dem Caching vollständiger Zeilen durch pg_local_cache 2.0. Sehen Sie, welche Arbeit ein Treffer im Zeilen-Cache vermeidet, welche Kosten bleiben und wann kein weiterer Cache nötig ist. Transaktionsbewusste Cache-Invalidation in PostgreSQLTesten Sie die Invalidation von pg_local_cache 2.0 mit gleichzeitigen PostgreSQL-Sitzungen. Prüfen Sie nicht bestätigte Updates, Read-your-writes, Rollback, bestätigte Lesevorgänge und Fallback-Regeln. Batch-Zeilenabfragen mit node-postgresVerwenden Sie pg_local_cache 2.0 aus Node.js mit einem parametrisierten bigint-Array und JSON-Transport. Erhalten Sie Reihenfolge und NULL-Werte und vergleichen Sie mit einer vorbereiteten ANY-Abfrage. Batch-Zeilenabfragen mit Go und pgxVerwenden Sie pg_local_cache aus Go mit pgx, parametrisierten Schlüsseln und dekodierten JSON-Zeilen. Über RESP verbindenLesen Sie PostgreSQL-Zeilen über RESP2 mit redis-cli oder Node.js. Enthält Authentifizierung, Client-Einstellungen, ausführbare Beispiele und Aufräumen. pg_local_cache auf PostgreSQL 14–18 installierenInstallieren Sie die pg_local_cache-PostgreSQL-Erweiterung mit verifizierten Linux-Binärdateien oder PGXS, konfigurieren Sie Preload und Neustart, prüfen Sie die Installation und stellen Sie sie sicher wieder her. Technische Referenz für pg_local_cacheTechnische Referenz für SQL-mget, transaktionsbewusste Invalidation, begrenzten PostgreSQL-Shared-Memory, Monitoring und optionales RESP2 von pg_local_cache.

Praxisnotizen zum PostgreSQL-Caching

Alle Artikel →

Vor dem Ausprobieren

Ersetzt das shared_buffers?

Nein. PostgreSQL cached Datenbankseiten. Diese Erweiterung cached separat serialisierte vollständige Zeilen per Primärschlüssel. Siehe den Vergleich der Lesepfade.

Cached es gewöhnliche SELECT-Abfragen?

Nein. Nur explizite Aufrufe von local_cache.mget verwenden den SQL-Cache. Ihre bestehenden Abfragen behalten den normalen PostgreSQL-Ausführungspfad.

Ersetzt es Redis?

Nein. Der optionale RESP2-Endpunkt ist begrenzt. Es gibt weder einen allgemeinen Redis-Befehlssatz noch TTL, Pub/Sub oder verteilte Koordination. Vergleichen Sie die PostgreSQL- und Redis-Cache-aside-Pfade.

Wie prüfe ich Updates und Rollback?

Der Invalidation-Leitfaden enthält einen Test mit zwei Sitzungen. Das ausführbare Beispiel prüft nicht bestätigte Schreibvorgänge, Read-your-writes, Rollback und bestätigte Updates.