Reprise du message précédent :
J’avais réfléchi à faire ça aussi car je bosse sur deux PC.
Mais au final pour mes projets c’était plus galere qu’autre chose.  
 
Si tu as déjà un server, ça change sûrement la donne. Mais ma config vscode se sync déjà entre mes PC et un git pull me mets à jour rapidement.  
 
En tout cas plus simplement que de payer un server + setup le truc + être sur d’avoir tjs internet (exemple le train).

C'est l'occasion d'une levée de fonds entre investisseurs HFRiens.  
J'ai des contacts (malgré moi) qui peuvent te faciliter une ICO.
 
Rien que Jubi et Hepha peuvent te financer une équipe entière de réfugiés ukrainiens.

Tu peux essayer en corrigeant juste le dernier index:

en supprimant le matching_id

Je suis curieux de voir la diff de perf (à l'instinct j'aurais dit quasi nulle)

 
Il est pas présent dans le dernier plan

koskoz > c'est quoi la répartition des valeurs de status ? (pour savoir si 'job_accepted' est très discriminant).

 
Sans celui la non plus:

Je suppose que le triple index sert à rien, et que un double index sur (status, timeslot_start_time) va suffire, sachant que t'as deja un index sur (pro_id)

https://explain.depesz.com/s/E0DE

L'index scan est beaucoup plus coûteux.

16 ms au lieu de 14ms, c'est bien ce qu'il me semblait c'est quasi nul comme diff (venant de 7 secondes).

 
Ça varie de 4-5ms à chaque exécution sur les deux plans.

en parlant de perf, je viens de passer 2h à bosser avec un truc super lent
 

Tes millimètres étaient en fait des pouces?

Postgres sait pas utiliser deux index, et là clairement il veut pas utiliser celui sur pro_id (stats pas à jour?). Donc il va se retrouver à nouveau à devoir filtrer le résultat de l’index scan.

 
Ouai mais l'index est plus général, potentiellement utile pour d'autres requetes, moins couteux,..etc..
De maniere generale, j'évite les index multiples sauf tres tres bonne raison.

Même si le temps d'exécution est semblable, pour l'index scan est beaucoup plus coûteux avec l'index sur les deux colonnes ?

Mais c’est toujours un index multiple, juste moins spécifique.  
 
En plus un index multiple peut être utilisé sur tous ses préfixes donc si tu veux le généraliser tu peux juste passer pro_id à la fin et comparer.

Du coup je le garde ou pas cet index ?

 
Ah ? C'est un comportement de Postgres ?

Wait, du coup

matching_pro.matching_pro_boblenain200_index (STATUS, timeslot_start_time, pro_id)

Equivaut également à

matching_pro.matching_pro_boblenain200_index (STATUS, timeslot_start_time)

Le prefix-matching c'est le comportement des btree, c'est tout l'intérêt, et c'est pour ca que les btree marchent avec des range requests, ou qu'un filtre de type field ILIKE 'value%' va pouvoir utiliser un btree (contrairement à un hash index). L'extension aux index composites suit la même logique.

Je présume et j'espère que les autres DBs fonctionnent sur le même principe, sinon c'est super con.

edit: en tout cas la doc de sqlite documente le même comportement:

(nb: la "table" de gauche représente un hypothétique index composite: https://www.sqlite.org/queryplanner [...] n_indices)

matching_pro.matching_pro_boblenain200_index (STATUS, timeslot_start_time, pro_id)

matching_pro.matching_pro_boblenain200_index (STATUS, timeslot_start_time)

Dans le sens où si t'as le premier le second sert pas à grand chose, oui. Le second va être un peu plus petit parce-que les clés sont plus courtes, mais je sais même pas s'il va avoir une notablement meilleure localité de data (parce-que je sais jamais trop comment les feuilles sont stockées exactement: est-ce que t'as une clé et n valeurs, ou est-ce que t'as une clé par valeur (donc des clés dupliquées)? Je crois que c'est le dernier mais je suis pas sûr.

C'est d'ailleurs pour ça que dans une db comme sqlite qui n'a pas de support spécifique pour les covering index, tu peux "élargir" ta clé avec les colonnes que tu veux ajouter ton overhead va être plus grand qu'avec un "vrai" covering index (INCLUDE) mais sinon ça marche: https://www.sqlite.org/queryplanner [...] ng_indices

Merci masklinn, je ne savais pas que l'ordre des clés d'un index était important

 
Un synology ça peut facilement hoster VSCode for web ? Ou faut jouer avec docker ?

Le plus simple reste Docker (J'ai pas vu sans sur les Syno). Mais mon NAS est vraiment pas puissant (DS 115j), il me sert juste pour mes films, il est en veille 90% du temps.

Ça a plein d'effets bizarres / intéressants, mais qui peuvent être super spécifiques à ta db.
 
Genre dans postgres un index unique et une contrainte unique sont plus ou moins équivalent (avec quelques différences: un index unique peut être partiel et concurrent, mais une contrainte unique peut être déférée).
 
Donc si t'as une table de jointure (a, b), et que tu as une contrainte UNIQUE (a, b), t'es couvert pour les cas où tu veux obtenir B à partir de A (select b from ... where a = ?), et les cas où tu veux vérifier l'existence d'un lien (select exists (select 1 from ... where a = ? and b = ?)), le seul cas pas couvert c'est si tu veux obtenir A à partir de B, si c'est un besoin tu peux vouloir créer un index sur B.

Dites les experts en frigo, on peut faire quoi quand un compresseur se met à vibrer à fond ? A part mettre des coups dedans et le secouer, ce qui le calme seulement quelques secondes avant de recommencer.  
Ça me rend dingue.  
 
Un dégivrage peut être ? Il a 3 ans seulement mais c’est un truc de merde de la marque Proline. Ça le fait pas toujours mais j’ai aucune solution. A part le bouger un petit peu ou lui appuyer dessus h24.

Ma cogip teste le 50G PON dans un village... dispo partout d'ici 2-3 ans.  
 
Est-ce qu'Harko aura la fibre d'ici là.

Vérifier qu'il y a pas un truc desserré ?

Y'a pas grand chose à faire, y'a rien d'accessible et tu peux pas le changer toi-même
ce qu'il y a autour et sur quoi tu peux intervenir :
silent blocs -> peut-êtres cuits, mal montés...
condensateur de démarrage du compresseur -> peut-être en train de crever
plasturgie autour du compresseur -> mal installée qui pourrait vibrer, mais j'imagine que tu l'aurais vu

Bah j'ai pas vraiment de truc à regarder. Enfin autour et à l'intérieur tout du moins, tout est bon. C'est vraiment dedans, au niveau du moteur que j'entends le bruit mais je sais pas trop comment on y accède. Je vais attendre de le vider + dégivrer pour pouvoir le manipuler plus facilement.

Ouais c'est ce que je me dis
Je l'ai vraiment pas payé cher, mais ça me fait chier de le changer car ça coute une blinde si j'en veux un de marque et surtout, il fonctionne quoi.

bah les silent blocs et le condo peuvent se changer
mais un frigo d'entrée de gamme qui fait du bruit, c'est pas anormal
je me souviens que dans la notice on mettait une fiche avec tous les bruits que font un frigo (genre "glouglou" ) pour dire : "c'est normal, n'appelez pas le SAV pour ça"

Tant que ça parle bricolage, comment je peux faire sauter le rivet d'une roue de valise (qui sert d'axe) ?
 
J'imagine qu'en bourinant avec un tournevis je vais juste exploser le plastique autour

 
Oui mais là il faisait jamais ce bruit depuis 3 ans.  
Et pis je l’entends porte de la cuisine fermé + casque avec musique. Ça fait vraiment BEAUCOUP de bruit.

un coup de perceuse dedans normalement
bon perso j'ai jamais réussi, le rivet s'était mis à tourner et à fondre le plastoc autour

si tu te barres en vacances vide ton frigo
un mode de défaillance c'est le compresseur qui serre et y'a pas grand-chose à faire quand t'es hors garantie à ce niveau de prix
c'est pas impossible qu'un jour il reparte pas
et puis peut-être que la lubrification va revenir à sa place, mais je suis pas très sûr de moi là dessus

De retour d'une journée de bilan pour loulou
Tous les voyants sont au vert
Prochain bilan a la Toussaint avec des mesures un peu plus poussés sous anesthésie générale (cathétérisme pulmonaire)

Oui donc job_accepted est très discriminant. C'était pour l'exemple cette valeur ou bien elle est genre en dur dans le code qui fait cette requête ?
Pour ta liste de pro_id et ton status job_accepted, c'est quoi la répartition en mois des données (pour savoir si un index triple est utile ou bien uniquement sur (pro_id, status) ?
Sachant que si tu crées un index sur (pro_id, status), tu pourras virer celui sur pro_id car il sera redondant.

C'est pareil avec MySQL depuis que j'utilise MySQL a minima (donc plus de 20 ans ) : https://dev.mysql.com/doc/refman/8. [...] dexes.html

C'est fondamental en effet

 
si jamais j'habite justement un petit village (PLZ: 8006 ), je suis prêt à tester comme il faut
 

sympa le vote de réintégrer les personnels de santé non vaccinés...c'est sur que c'est une bonne idée de réintégrer du personnel soignant qui croit pas aux fondements de la médecine moderne