Skip to content

Instantly share code, notes, and snippets.

@NerOcrO

NerOcrO/postgresql.md

Last active August 26, 2025 16:17
Show Gist options
  • Save NerOcrO/c26a663c57b99761e4fe5aef17414fc1 to your computer and use it in GitHub Desktop.
Save NerOcrO/c26a663c57b99761e4fe5aef17414fc1 to your computer and use it in GitHub Desktop.
Download ZIP
postgresql sql
Raw
postgresql.md
  • SQL est Turing complete
  • null veut dire "on ne sait pas" en postgres
  • Data Types
  • CTE : Common Table Expression avec un WITH pour séparer les responsabilités (comme une fonction)
  • on stocke une donnée qui ne change jamais : une date de naissance oui ! mais pas l'age...
  • le mot ALWAYS permet de dire qu'on ne peut pas écrire manuellement dans le champ

Flux d'une requête

  • from/join (uniquement ici où on prend la data, tout le reste n’est que filtre)
  • where
  • group by
  • aggregate functions
  • having
  • window functions
  • select
  • distinct
  • union/intersect/except
  • order by
  • offset
  • limit/fetch/top

Docker

  • A priori, on ne peut pas avoir les logs en stdout...
  • SHOW config_file pour voir où est le fichier de config
  • docker exec -it pc-postgres cat /var/lib/postgresql/data/postgresql.conf
  • docker exec -it pc-postgres cat /var/lib/postgresql/data/log/postgresql-2020-03-16_144749.log
  • docker exec -it pc-postgres tail -f /var/lib/postgresql/data/log/postgresql-2020-03-17_103605.log

Bonnes pratiques

  • le point virgule est super important !
  • si date de début et date de fin alors on peut créer un champ de type range
  • au lieu de mettre une date de fin à null, plutôt utiliser infinity
  • utiliser un id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, cela :
    • génère une séquence
    • ajoute la prochaine valeur séquencée quand on insert par défaut
    • empêche l'écriture manuelle sur cette colone ! on est obligé d'utiliser une séquence
    • tout ça évite d'être désynchronisé
  • on peut créer un generated column (lecture seule) pour faire un calcul d'age par exemple pour éviter de le faire dans le code et il se met à jour à chaque fois que l'on modifie la ligne
  • Ne pas avoir trop de jointure (et donc moins de table)
  • pas toujours utile de mettre un index sur un champs
    • si trop peu de ligne : contre productif
    • ça ralentit l’écriture
    • ça améliore une requête mais peut ralentir les autres
    • s’il y deux fois plus d’index que de data, c’est très con (en terme d’octet)
      • \d pg_stat_all_indexes
  • postgres se base sur les statistiques pour faire ses optimisations donc attendre de faire vivre sa bdd pour voir comment y mettre des index
  • Parallélisme
  • Ne pas faire de ALTER lors d'une migration car ça pose un lock (ZDD) en version 10 mais en 11, ça passe mieux.
  • OUTER JOIN ne sera pas plus lent que INNER JOIN sur un test avec quelques dizaines de lignes
  • psql -U [USER] [DB]
  • SET search_path TO [SCHEMA];
    • ou sinon SELECT * FROM [SCHEMA].notification;
  • \dt pour voir les tables
  • \dT pour voir les énumération

Outils

Vidéos

Extensions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment