pg_local_cache
Français

Un cache de lignes
dans PostgreSQL.

Lisez des lignes par clé primaire avec mget SQL ou RESP. Les écritures PostgreSQL invalident automatiquement les entrées de cache concernées.

Essayer localement Comparer au SQL

API SQL explicite · PostgreSQL 14–18 · Open source

Mesuré localement · 15 sept. 2026

839,678requêtes/s · RESP MGET

3.31× le débit SQL préparé
dans cette comparaison à clé unique

SQL préparé
253,790 req/s
SQL mget
186,296 req/s
Apple M3 Max · PostgreSQL 16 · Go · 256 connexions.
Cache chaud, 1 clé/requête. Médiane de 3 × 5 secondes.
SQL mget était plus lent ici ; les résultats par lots diffèrent.
Résultats, données brutes et conditions

Un appel. Deux chemins de lecture.

Un hit éligible renvoie la ligne stockée. Un miss ou un contournement lit la table source. Vos requêtes SELECT ordinaires gardent leur chemin actuel.

psql │ lectures par clé primaire
-- 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[]
);

Exemple Node.jsExemple GoExemple RESP

Chemin de lecture SQL mget L'application appelle local_cache.mget dans PostgreSQL. Après les vérifications d'éligibilité et de snapshot, un hit du cache renvoie la charge utile stockée de la ligne complète. Un miss ou un contournement lit la table source. Les deux chemins renvoient les lignes via la même connexion PostgreSQL. PostgreSQL Application local_cache.mget Éligibilité + snapshot Trouvé Absent / ignoré Stockéeligne Sourcetable
Les deux chemins renvoient des lignes complètes sérialisées via la même connexion PostgreSQL. Une lecture éligible de la table source peut remplir le cache.
Ce qu'évite un hit du cache de lignes
SQL mget

Jusqu'à 1 024 clés par appel. L'ordre, les doublons et les positions NULL sont conservés.

Écritures ordinaires

INSERT, UPDATE et DELETE invalident les entrées concernées.

Capacité fixe

Allouez le cache de lignes partagé au démarrage de PostgreSQL.

Vérifications du snapshot

Les lectures non éligibles utilisent la table source selon les règles de visibilité de PostgreSQL.

Lancez le même test.
Avec chaque client.

Node.js et Go. SQL préparé, SQL mget et RESP MGET.

Un seul exécuteur utilise les mêmes clés, tailles de lots, nombres de connexions, durée et vérifications des résultats. Comparez le débit, la latence, ainsi que le CPU et la mémoire PostgreSQL sur votre machine.

Lancer la comparaison

Cette charge vous correspond-elle ?

Vous choisissez un cache ? Comparez les pages PostgreSQL, les lignes, les vues matérialisées et Redis.

À mesurer

  • Lectures répétées de lignes complètes par clé primaire.
  • Un petit ensemble chaud de lignes complètes.
  • READ COMMITTED sur un primaire inscriptible.
  • Une application capable d'appeler l'API SQL explicite.

Gardez le SQL ordinaire

  • Jointures, plages, agrégats ou résultats de requêtes arbitraires.
  • Tables avec RLS, partitionnées ou héritées.
  • Une base de données où vous ne pouvez pas installer d'extension native.
  • Charges de travail sans bénéfice mesuré.

Lancez une démo locale.

Clonez le dépôt et démarrez un serveur PostgreSQL éphémère avec des lignes d'exemple. Docker compile l'extension et garde la démo séparée de vos bases de données.

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

Lisez les lignes d'exemple et vérifiez les hits du cache. Vous avez déjà cloné le dépôt ? Exécutez la dernière commande depuis sa racine. Pour un serveur existant, utilisez le guide d'installation.

L'installation sur un serveur existant nécessite un redémarrage de PostgreSQL.

Documentation

Essayer pg_local_cache localementExécutez pg_local_cache 2.0 dans un PostgreSQL éphémère, lisez des lignes d'exemple, inspectez les hits du cache, testez les mises à jour et supprimez la démo sans modifier une base existante. Benchmarks du cache PostgreSQLRésultats mesurés de pg_local_cache avec Node.js, Go et RESP sur Apple M3 Max. La machine, le CPU PostgreSQL, la mémoire et la méthode sont inclus. Guide de décision sur la mise en cache PostgreSQLChoisissez la mise en cache des pages PostgreSQL, le SQL préparé, le cache de lignes complètes, les vues matérialisées ou un cache externe selon le travail à éviter. Cache-aside PostgreSQL et RedisUtilisez PostgreSQL comme source de vérité avec un chemin cache-aside Redis, comprenez les courses de lectures obsolètes et voyez où se place pg_local_cache. Recherches PostgreSQL par clé primaire en lotsRemplacez les lectures de clés primaires N+1 par une requête PostgreSQL paramétrée, conservez les positions d'entrée si nécessaire et comparez le chemin mget explicite de pg_local_cache. Cache de lignes PostgreSQL contre shared_buffersComparez la mise en cache des pages PostgreSQL au cache de lignes complètes pg_local_cache 2.0. Voyez ce qu'évite un hit, ce qu'il coûte encore et quand ne pas ajouter un autre cache. Invalidation du cache PostgreSQL tenant compte des transactionsTestez l'invalidation pg_local_cache 2.0 avec des sessions PostgreSQL concurrentes. Vérifiez les mises à jour non validées, la lecture de ses propres écritures, le rollback, les lectures validées et les règles de repli. Recherches de lignes par lots avec node-postgresUtilisez pg_local_cache 2.0 depuis Node.js avec un tableau bigint paramétré et un transport JSON. Conservez l'ordre et les valeurs nulles, puis comparez avec une requête ANY préparée. Recherches de lignes par lots avec Go et pgxUtilisez pg_local_cache depuis Go avec pgx, des clés paramétrées et des lignes JSON décodées. Se connecter via RESPLisez des lignes PostgreSQL via RESP2 avec redis-cli ou Node.js. Authentification, paramètres client, exemples exécutables et nettoyage inclus. Installer pg_local_cache sur PostgreSQL 14-18Installez l'extension PostgreSQL pg_local_cache avec des binaires Linux vérifiés ou PGXS, puis configurez le preload, redémarrez, vérifiez et récupérez-la en toute sécurité. Référence technique de pg_local_cacheRéférence technique de pg_local_cache : mget SQL, invalidation tenant compte des transactions, mémoire partagée PostgreSQL bornée, supervision et RESP2 optionnel.

Notes pratiques sur la mise en cache PostgreSQL

Tous les articles →

Avant d'essayer

Est-ce que cela remplace shared_buffers ?

Non. PostgreSQL met en cache les pages de la base de données. Cette extension met séparément en cache des lignes complètes sérialisées par clé primaire. Consultez la comparaison des chemins de lecture.

Met-il en cache les requêtes SELECT ordinaires ?

Non. Seuls les appels explicites à local_cache.mget utilisent le cache SQL. Vos requêtes existantes gardent le chemin d'exécution PostgreSQL normal.

Remplace-t-il Redis ?

Non. Le point de terminaison RESP2 optionnel est limité. Il n'y a ni ensemble général de commandes Redis, ni TTL, ni pub/sub, ni coordination distribuée. Comparez les chemins cache-aside PostgreSQL et Redis.

Comment vérifier les mises à jour et le rollback ?

Le guide d'invalidation contient un test à deux sessions. L'exemple exécutable vérifie les écritures non validées, la lecture de ses propres écritures, le rollback et les mises à jour validées.