Je ne remercie absolument pas l'évolution pour avoir à ce point foiré le sommeil humain Ça n'est pas possible de fonctionner aussi mal. T'essayes de te coucher tôt pour tenter de retrouver une certaine forme. Résultat, tu te réveilles à 4h30, et impossible de te rendormir, car c'est le moment où le cerveau à en fait décider d'enclencher son cronjob "brain-overthink.sh"

il y a toujours des variations suivant le gueule des données et les ressources / charge, mais 100M de ligne je commence juste à me poser la question du partitionnement
(ajouter un index peut te couter très cher si tu effaces beaucoup de données, donc , surtout sur les grosses table il ne faut pas regarder que le temps de requetes, mais aussi celui de vacuum )

 
Ca sera du append-only, on historise tout. Jamais de deletes sauf sur une seule table qui servira de status à l'instant présent, donc a priori pas trop de vacuum. Et il y aura des temps de downtime pour faire de la maintenance, généralement le weekend, donc on est assez tranquilles de ce côté-là.
 
La plus grosse table ferait environ 50 millions de lignes/an (10 ans de rétention soit 500 millions de lignes max) sauf si on décide de sauvegarder les données sous forme de jsonb, auquel cas on divise le nombre de lignes par 70 et on n'aurait plus de problème de ce côté-ci.

Combien de RAM et quel storage ?

Sub seconde même + de 100M de ligne avec un index b tree et si tu règles correctement l'autovacuum + effective cache size, c'est largement OK.

Je ne me prendrais pas la tête en dessous de 100M de lignes en tout cas.

As-tu besoin de cela, ou bien sqlite suffira pour ton besoin là est la question

C'est donc encore mieux, aucun stress selon moi.

A la limite du partitionnement par année pour des raisons business pourrait faire du sens si vraiment besoin réel, sinon les conditions paraissent optimales pour postgres + sub seconde.

 
Ca sera du append-only, on historise tout. Jamais de deletes sauf sur une seule table qui servira de status à l'instant présent, donc a priori pas trop de vacuum. Et il y aura des temps de downtime pour faire de la maintenance, généralement le weekend, donc on est assez tranquilles de ce côté-là.
 
La plus grosse table ferait environ 50 millions de lignes/an (10 ans de rétention soit 500 millions de lignes max) sauf si on décide de sauvegarder les données sous forme de jsonb, auquel cas on divise le nombre de lignes par 70 et on n'aurait plus de problème de ce côté-ci.

 
Ca sera du append-only, on historise tout. Jamais de deletes sauf sur une seule table qui servira de status à l'instant présent, donc a priori pas trop de vacuum. Et il y aura des temps de downtime pour faire de la maintenance, généralement le weekend, donc on est assez tranquilles de ce côté-là.
 
La plus grosse table ferait environ 50 millions de lignes/an (10 ans de rétention soit 500 millions de lignes max) sauf si on décide de sauvegarder les données sous forme de jsonb, auquel cas on divise le nombre de lignes par 70 et on n'aurait plus de problème de ce côté-ci.

append only, je suis d'accord avec devil : le partitionnement est trivial par date , et ça simplifiera la vie a ton successur dans 10 ans qui voudra effacer 50M lignes d'une table de 500M
J'aime pas trop le jsonb pour des données dont on connait le format

Les deux solutions ont leurs avantages et leurs inconvénients. Le choix se fera sur le besoin ou non de faire de l'analytics sur les données. Si oui, alors je pense garder les données sous forme de rows séparées, sinon je pense que des documents en jsonb l'emporteront et le nombre de lignes tombe à moins d'un million/an.

En terme de requêtes, je pense que ça se vaut: d'un côté, la syntaxe jsonb est un peu plus lourde, de l'autre, s'il faut faire des requêtes sur des partitions, ça fait des UNION et autres sataneries s'il faut faire des requêtes sur plusieurs partitions.

Pour ce qui est du nettoyage, c'est vrai qu'un drop table ou un truncate table, c'est instantané, mais si on fait un nettoyage annuel de quelques centaines de milliers de lignes lors d'un weekend, quand la base est inutilisée, ça ne devrait pas être un gros problème, si ?

Row >>> jsonb.
 
Jsonb qui dépasse 8kb (de souvenir ca date la dernière fois que j'ai regardé ca) est envoyé ailleurs dans le disque, perf au rabais donc. Au passage tu as les clefs, donc perd de l'espace disque.

Non les partitions sont très bien gérées par PG, c'est transparent, le fait que la table soit partitionnée ou non est transparent niveau code, imaginons que tu as une table "factures" partitionnée par mois:
SELECT * FROM factures => full scan de la table, toutes les partitions
SELECT * FROM factures WHERE created_at = "2025-01-01" => PG s'occupera de prendre juste la bonne partition
 
0 union a faire, tu ne touches ni ne travaille avec les partitions, ca c'est le job de PG.
 
Donc je pense que c'est là ou tu as raté un point: le partitionnement est accessible si tu veux, mais la plupart du temps tu travailles avec "la table mere" et du côté code, ca s'utilise comme si il n'y avait pas de partition.

Pour ce qui est du nettoyage, c'est vrai qu'un drop table ou un truncate table, c'est instantané, mais si on fait un nettoyage annuel de quelques centaines de milliers de lignes lors d'un weekend, quand la base est inutilisée, ça ne devrait pas être un gros problème, si ?

en vrai j'ai eu ça dans un précédent job : la table se remplissait plus vite que DELETE+ VACUUM
 
(il y avait tellement de fun empilé)

Je ne remercie absolument pas l'évolution pour avoir à ce point foiré le sommeil humain Ça n'est pas possible de fonctionner aussi mal. T'essayes de te coucher tôt pour tenter de retrouver une certaine forme. Résultat, tu te réveilles à 4h30, et impossible de te rendormir, car c'est le moment où le cerveau à en fait décider d'enclencher son cronjob "brain-overthink.sh"

Je pense que la situation était légèrement différente  

Le truc est tellement mal implémenté. L'idée de base est ok, on profite des moments de répit pour faire la maintenance du cerveau. Mais l'aspect "oh non là il est 2h du matin mais je préfère que tu penses un peu plus à ce que t'a dit ton chef à la réunion, on en rediscute dans 3h xoxo" suivi de "comment ça il est 15h et tu n'as dormi que 5h cette nuit, le mieux que je puisse faire pour toi c'est bailler et fermer les yeux sans pouvoir résister".  
 
Puis l'injustice entre ceux qui sont parfaitement fonctionnels à 6h de sommeil vs ceux qui ont besoin de 9h, genre toi dans la vie t'auras 3h de moins par jour, vas te faire foutre...

il y avait 3 ( ou 4x ) plus d'espace disque utilisé par les index que les données  
 
mais les requêtes étaient rapides, chaque deva avait mis ses propres index en gros

Dans ce cas partitionne par mois ou année, ca te simplifiera la vie quand il sera question de supprimer les vielles tables/données.

append only, je suis d'accord avec devil : le partitionnement est trivial par date , et ça simplifiera la vie a ton successur dans 10 ans qui voudra effacer 50M lignes d'une table de 500M  
J'aime pas trop le jsonb pour des données dont on connait le format

Row >>> jsonb.
 
Jsonb qui dépasse 8kb (de souvenir ca date la dernière fois que j'ai regardé ca) est envoyé ailleurs dans le disque, perf au rabais donc. Au passage tu as les clefs, donc perd de l'espace disque.

 
Je ne remercie absolument pas l'évolution pour avoir à ce point foiré le sommeil humain Ça n'est pas possible de fonctionner aussi mal. T'essayes de te coucher tôt pour tenter de retrouver une certaine forme. Résultat, tu te réveilles à 4h30, et impossible de te rendormir, car c'est le moment où le cerveau à en fait décider d'enclencher son cronjob "brain-overthink.sh"

il semblerait que le fentanyl c'est top. Maintenant quand je passe à la gare de Zurich je vois des gens pliés en 2 qui dorment, voir d'autre par terre dormant dans leur propre pisse, ça a l'air super efficace.
Après j'étais pas là à 5h du matin, peut-être qu'ils étaient préoccupés

J'aurais jamais cru dire ça de ma vie, mais je regrette les drogués de la Riponne (à Lausanne c'est LE coin des drogués, avec petite camionnette propre qui distribue des seringues gratuitement, et un service qui vient chercher les gens pour les faire dormir dans des centres spécialisés où on leur propose des traitements de substitution pour s'en sortir).
Zurich on est passé des bisounours à San Francisco en 2 ans, c'est assez moche à voir.

Encore une municipalité de gauchiasse, je te foutrais l'UDC au milieu, j'aime autant te dire que l'écriture inclusive* et les clodos drogués se tiendraient à carreau

*: je sais pas pour les drogués, mais ils ont proposé une votation pour mettre fin à l'écriture inclusive pour les administrations, genre "Wir stellen Fahrer*innen ein". Il faut savoir se concentrer sur les vrais problèmes du peuple

Les salles de shoot, c'est pourtant la moins mauvaise solution pour tout le monde Ceux qui veulent se droguer le feront de tout manière, avec ou sans salle de shoot. C'est absolument pas incitatif. Et là, au moins, ça cadre le truc : ils font pas ça n'importe où en particulier dans les gares ou parcs à la vue de tous, notamment les enfants et avec les seringues distribuées, ils risquent pas de choper des maladies. Bref, c'est sécuritaire pour tous. Ce mot, "sécuritaire", ça devrait plaire à la Droite, non ?  

J'ai découvert récemment que Badinter, en plus d'avoir fait abolir la peine de mort, avait dépénalisé l'homosexualité. 2 grosses lois sociétales à son actif en peu de temps. Et maintenant Charlie et Lulu qui font les ultimes négociations des ultimes négociations des dernières négociations pour former un gouvernement qui va pas sauter au bout de qq jours. C'est d'un autre niveau la politique de nos jours...  

 
Si tu vas par là, Giscard durant son seul mandat

• majorité à 18 ans
• réforme du Conseil constitutionnel
• suppression de l'ORTF
• légalisation de l'IVG
• divorce par consentement mutuel (c'était forcément pour faute avant)
• le collège unique (on repousse les filières pro au lycée)
  

/vent
Tain je suis sur un produit complexe en terme d'architecture, et notre PMT pige rien techniquement, ca va faire deux ans qu'il est sur le produit pourtant
Mon manager essaye de compenser mais ca suffit pas, et il a d'autres trucs a faire

/vent
Tain je suis sur un produit complexe en terme d'architecture, et notre PMT pige rien techniquement, ca va faire deux ans qu'il est sur le produit pourtant
Mon manager essaye de compenser mais ca suffit pas, et il a d'autres trucs a faire

 
Si tu vas par là, Giscard durant son seul mandat

• majorité à 18 ans
• réforme du Conseil constitutionnel
• suppression de l'ORTF
• légalisation de l'IVG
• divorce par consentement mutuel (c'était forcément pour faute avant)
• le collège unique (on repousse les filières pro au lycée)
  

il semblerait que le fentanyl c'est top. Maintenant quand je passe à la gare de Zurich je vois des gens pliés en 2 qui dorment, voir d'autre par terre dormant dans leur propre pisse, ça a l'air super efficace.
Après j'étais pas là à 5h du matin, peut-être qu'ils étaient préoccupés
 
J'aurais jamais cru dire ça de ma vie, mais je regrette les drogués de la Riponne (à Lausanne c'est LE coin des drogués, avec petite camionnette propre qui distribue des seringues gratuitement, et un service qui vient chercher les gens pour les faire dormir dans des centres spécialisés où on leur propose des traitements de substitution pour s'en sortir).
Zurich on est passé des bisounours à San Francisco en 2 ans, c'est assez moche à voir.
 

Tain le prix nobel de Physique travaille à Google. Cette boite quand même c'est quelque chose. J'aurais pas de famille j'aurais tellement essayé d'aller chez Google Quantum AI.