Reprise du message précédent :
Ça y est, le débat sur l'apres feu..

Dans déconner, il a brûlé environ 10% de ce qu'avait abattu la tempête, mais la, le camping de Patrick a cramé, du coup c'est très très grave.

 
Bah au delà de Patrick, le fait d’avoir des feux autant au nord, c’est clairement une des choses anticipées avec le RC. De plus en plus de feux et de plus en plus au nord avec une sécheresse de plus en plus importante.

Des feux il y en avait beaucoup plus dans les années 50-60, jusqu'à celui qui a fait 82 morts en 59 ou 60, a 10 bornes de bordeaux.

C'est de la que datent les plans de lutte, les pare feux, les plans de gestion et tout et ça a plutôt bien marché (et globalement ça marche encore, faut peut être revoir les largeurs de pare feu et d'autres paramètres, mais globalement ça fonctionne)

Ça veut pas dire que le réchauffement n'aggrave pas les choses, cela dit.

 
Je parle pas de Bordeaux mais des feux qui ont eu lieu en Bretagne et dans le Finistère. Il y a eu aussi des feux ici au UK et ça c’est vraiment nouveaux. Bordeaux il y a toujours eu des canicules. J’en ai connu quand j’y vivais il y a 30 ans.

Ok, je parlais au départ en réaction à Manu Le Macron a La Teste

Et sinon ça fait 15 ans que je vis a Bordeaux, et des canicules comme ça (juin et juillet), on en a eu mais jamais aussi rapprochées, et surtout j'ai pas souvenir que ça ait été aussi sec.
Normalement a la fin d'une journée a 40 il y a un orage avec de la pluie
Là on a eu 3 éclairs et c'est tout.
Il a fait un peu humide hier soir, et c'est tout

Ouais, je me rappelle encore dans les années 80 il y en avait pas mal ... J'ai des souvenirs d'un des plus gros au porge. (J'ai passé tout mes été de 1980 a 1995 dans le coin ... Et une très grande majorité de la famille vit là bas).

J'entame une nouvelle mission en C++ 17, je suis déjà dépassé

A 2 pas du bois de Vincennes

Je ne pensais pas dire cela un jour ici au UK, mais ... Il pleut.  

en fait julia a juste un système de types dynamiques, simplement y'a des anotations qui sont vérifiées à certains endroits.  
 
Mon collègue a appelé un constructueur qui a zéro chances d'exister comme valeur par défaut d'une fonction, et le système l'a laissé faire parce que les constructeurs sont des fonctions normales et les fonctions c'est un pb de runtime, pas de compilateur.
 
Le point saillant c'est que les tableaux ont le type de leurs éléments écrit dedans.

Hihi un DAO (enfin une platform web3 appellée Jubi DAO) veut acheter mon nom de domaine jubi.io . Ils m’ont expliqué qu’ils ont 6 mois de funding et pas beaucoup de thunes  
 
Je me tâte

Vers Nice on attend la pluie... pour octobre comme d'hab

Tu prends le pognon et tu le donnes à une asso pour le climat ?  

 
 
j'ai jamais eu autant de bol d'avoir utilisé une VM

Bon, plutôt satisfait de mon setup:
 
Une VM linux headless dans XCP-NG derrière le serveur Wireguard de la Freebox.
 
J'utilise VSCode Remote (J'ai testé Pycharm en remote mais il me bouffe toute la RAM quelle que soit la quantité) et un tmux dans lequel j'ai mes terminaux et mes serveurs qui tournent.
 
Je peux bosser de n'importe quelle machine avec Internet et j'ai rien à installer localement.
 
Edit: J'avais pas vu le poste de nraynal

 
Pas mal. Si je n'étais pas un gros flemmard, je ferais un truc du même genre.

Les pros du SQL, j'ai besoin d'aide !
 
J'ai le schéma suivant :
 

CREATE TABLE job
(
    id varchar(255) NOT NULL
        constraint job_pkey
            PRIMARY KEY,
    last_matching_id uuid
);
 
CREATE UNIQUE INDEX uniq_fbd8e0f8f3ae09b4
    ON job (last_matching_id);
 
CREATE TABLE matching
(
    id     uuid         NOT NULL
        constraint matching_pkey
            PRIMARY KEY,
    job_id varchar(255) NOT NULL
        constraint fk_dc10f289be04ea9
            REFERENCES job
);
 
ALTER TABLE job
    ADD constraint fk_fbd8e0f8f3ae09b4
        FOREIGN KEY (last_matching_id) REFERENCES matching;
 
CREATE INDEX idx_dc10f289be04ea9
    ON matching (job_id);
 
CREATE TABLE matching_pro
(
    id                  uuid NOT NULL
        constraint matching_pro_pkey
            PRIMARY KEY,
    matching_id         uuid
        constraint fk_c5691da4b39876b8
            REFERENCES matching,
    pro_id              uuid,
        STATUS varchar (255) NOT NULL,
    timeslot_start_time timestamp(0) WITH time zone DEFAULT NULL::timestamp WITH time zone
);
 
CREATE INDEX idx_c5691da4b39876b8
    ON matching_pro (matching_id);
 
CREATE INDEX idx_c5691da4c3b7e4ba
    ON matching_pro (pro_id);
 
CREATE UNIQUE INDEX matching_pro_unique
    ON matching_pro (matching_id, pro_id);
 
CREATE UNIQUE INDEX matching_pro_unique
    ON matching_pro (matching_id, pro_id);
 
CREATE INDEX matching_pro__index
    ON matching_pro (matching_id, STATUS, timeslot_start_time)

 
Notez le dernier index.
 
Et la requête suivante :
 

SELECT
    COUNT(m0_.pro_id) AS sclr_0
FROM
    matching_pro m0_
        INNER JOIN
    matching m1_
    ON
            m0_.matching_id = m1_.id
        INNER JOIN
    job j2_
    ON
                m1_.job_id = j2_.id
            AND (j2_.last_matching_id = m1_.id)
WHERE
        m0_.STATUS = 'job_accepted'
  AND m0_.pro_id IN (
                     'df9370bf-6d4b-4fcf-aa8e-e1c4ccb0446e',
                     'b1879d57-e7bf-43b4-9a4b-e67cbbe5ed1a',
                     'a645ae73-352e-4133-89c3-0de530054a09',
                     'a5a5ae28-5f44-4406-9345-872a7a2e43ca',
                     '8dc2d5fb-2473-4695-835b-69894c9cef0a',
                     '848f2e91-be8a-4732-b53e-402e9395610e',
                     '818637f0-5530-40cb-9abe-63072c1b9dfc',
                     '6748f2d2-5a3b-4cfa-b7e2-6bc8263263bc',
                     '637704a5-870b-4526-bee2-81d09d2575d8',
                     '537f497b-8934-4be1-b361-365c59beeace',
                     '4c448f0a-cf09-458f-9335-7b545436d4d8',
                     '48c46dd1-0809-4627-8700-97d44291764e',
                     '3a1380c3-2ed7-429d-be02-b2897229e09f',
                     '364b8663-3c6f-471e-b8b3-fc6707cf6cd8',
                     '18584e1b-6545-4403-90d5-b2a3e5c64b37',
                     '03e9857f-fd84-4c41-98ea-42851d92b1a0'
    )
  AND m0_.timeslot_start_time >= make_date('2022', 7, 1)
  AND m0_.timeslot_start_time < make_date('2022', 8, 1)
GROUP BY
    m0_.pro_id;

 
Le plan d'exécution : https://explain.depesz.com/s/VzML
 
En local, cette requête met quasi 7 secondes à s'exécuter...
En prod c'est mieux mais ça reste long, 3 secondes environ.
 
Vous voyez un moyen quelconque de l'optimiser ?

Index sur timeslot_start_time?
 
Ah merde le code est tronqué en portait sur le tel j'avais pas vu qu'il était inclus

Index sur (pro_id, status, timeslot_start_time) ?

Ya ptet moyen de gagner un peu avec un INCLUDE (job_id) sur ton index, histoire qu'il soit pas trop obligé d'aller taper dans la table pour appliquer son filtre? (et son aggreg mais à ce stade ça coute plus grand chose).

Mais il faudrait voir si tu pourrais partir de et filtrer le join entre matching et job, parce-que là il part de ça puis il filtre avec l'index scan sur matching_pro. Donc si tu sais avoir moins de 80K en sortie du join (job, matching) tu devrais pas mal gagner.

À tester aussi, ça pourrait nudger l'optimiseur dans l'exécution de la query dans l'ordre de son écriture au lieu de faire l'inverse.

Ça pourrait même un index partiel sur status = 'job_accepted' s'il y a pas d'autres requêtes qui ont besoin de cet index spécifique.

Je te recommande d'utiliser de meilleurs outils:
 
https://explain.dalibo.com/
 
Car ton outil la il donne bien peu d'info en fait pour savoir ce qui se passe
 
Sinon bon ben avec les logs "raw" tu as ta réponse:
 Nested Loop (cost=3,036.33..7,335.44 rows=1 width=16) (actual time=5,225.931..7,987.517 rows=51 loops=1)  
 Hash Join (cost=3,035.78..7,331.45 rows=1 width=32) (actual time=1,739.433..4,588.820 rows=81,380 loops=1)  
 Seq Scan on matching m1_ (cost=0.00..1,955.38 rows=96,838 width=24) (actual time=0.022..966.656 rows=96,838 loops=1)  
 Seq Scan on job j2_ (cost=0.00..1,335.11 rows=81,511 width=24) (actual time=0.033..843.880 rows=81,511 loops=1)  
 
En gras les trucs a zieuter
 
Et les liens:
https://use-the-index-luke.com/sql/ [...] operations
https://www.cybertec-postgresql.com [...] ostgresql/
 
En gros ton soucis n'est pas sur ton index si c'est ca ta question, mais sur les seq scan et le hash join (ca peut etre plus dur a opti que le seq scan).

 
En plus de l'index sur  (matching_id, status, timeslot_start_time) ou à la place
 

 
J'ai jamais vu "INCLUDE" sur un index, je vais rtfm
 
Pareil, je ne connais pas les index partiels
 

 
Je ne connaissais pas, je regarderai
 
Par contre "mon" outil donne toutes les infos que tu as collées
 
J'avais bien compris que le problème ne venait pas de mon index, il n'y en avait pas avant j'ai vu la différence

À la place je dirais. Mais je dit ça au pifomètre

Une question que je me pose : comment twitter fait pour me suggérer du contenu "basé sur mes retweets" alors que je n'ai jamais rien retweeté de ma vie ?

 
Il se base sur ce qu'aiment les gens qui ne retweetent jamais rien ?  

Ah oui ya l'onglet stat Je prefere quand meme l'autre
 
Enfin en gros d'ab, ton soucis est surtout les seq scans, ca tue tout (= full scan de la table)

TikTok me suggère d'ajouter Jubi "dans mes contacts" alors que je l'ai nulle part à ma connaissance...

 
Ça aussi j'ai bien compris mais je ne sais pas comment le régler

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

 
   
 
Merci tryptique

Include c'est des index "couvrants", ça permet d'avoir des données stockées dans l'index qui ne sont pas dans la clé, donc ça augmente les chances d'index-only scans et la possibilité de filtrer les tuples sans sortir de son index.
 
Ça augmente la taille de l'index (vu qu'il faut quand même stocker la donnée supplémentaire) mais ça change pas le nombre d'entrées, ce qui est souvent avantageux.

De rien

 
Merci pour l'explication

Pour faire plaisir à Devil'sTiger
 
https://explain.dalibo.com/plan/4rT
 
   
 
C'est effectivement plus beau mais je ne trouve pas ça clair.

 
Excellent setup

On va essayer d'expliquer mais je sens que ca va etre confus
 
En gros un seq scan = full scan de la table, donc il prend chaque ligne et test.
 
Ce qui est parfois voulu, et puis parfois une mauvaise chose.
 
 
 
Mais pour bien piger faut commencer par le cambouis, a savoir comment ca marche en interne...
 
 
 
 
Donc tu full scan, admettons: tu vas avoir donc une lecture de la table, MAIS il y a lecture et lecture. Tu as la lecture brut, sur l'IO du disque, et la lecture sur cache (géré par ton OS dans le cas de PG), et puis par dessus tu peux avoir meme la lecture en ram (on va pas rentrer dans celui la).
 
 
Le plus souvent, a machine identique, si tu as des perfs différente entre une a 3sec et une a 7 ca repose sur ce passage. Imaginons que tu es pas ton index qui regle ton soucis de perf (et donc toujours la query a 7sec), et admettons que ca soit a peu pres acceptable en perf, l'étape 2 est de recommencer en ayant le cache clean, sous linux:

 
Car PG repose son cache sur le cache systeme.
 
Et recommence ta query, si elle est toujours rapide avec ET sans cache, bonne nouvelle, sinon, t'a encore du boulot.
 
Reste a savoir comment savoir si ton cache est plein ou non, htop sous linux est ton meilleur ami:
 
 

 
La partie "rouge" a une progress bar verte puis jaune => la zone jaune c'est le cache IO de linux. Ici il est donc plein (donc si je veux tester que ma query est toujours bonne en toute circonstance faudrait que je clean avant de re-run).
 
La partie "jaune" (les D, R & co) indique, quand une query prend du temps, ce que PG est entrain de faire, certains l'explique mieux que moi: https://peteris.rocks/blog/htop/#process-state
En gros:
D => PG est entrain d'attendre l'IO du disque
R => PG est sur le CPU
 
Et avec ca + les trace de query que tu as, tu as deja pas mal d'outil pour piger ce qui se passe et ou et comment ca bloque.
 
 
 
 
Maintenant pour éviter un seq scan, le plus rapide (et le plus classique) est souvent de... créer un index, ce que tu as fait avec brio
 
Il y a plein de technique dégeu cela dit, a base de ramdisk et de trifouillage du truc pour forcer PG a avoir tout en RAM par exemple Mais bon c'est pas ton use case je pense
 
 
 
Te voila expert en debugging PG maintenant

C'est le moment de pivoter pour fournir un concurrent à Gitpod et GitHub codespaces.
 
À toi les marges du SaaS.

 
Bonjour le taff (pour arriver à avoir de la marge). L'avantage du On prem c'est qu'on a quasi rien chez nous

Le INCLUDE c'est pour les index couvrant.
Ça peut être utile dans certains cas, ça évite de refaire un seek sur la table initiale pour récupéré les champs voulus.
Au lieu d'avoir une table de hash avec que la clé, vois cela comme une table de hash avec clé et quelques champs.

Par contre je me demande si je ne vais pas tester ce setup

 
Ce genre de setup est vachement intéressant, mais au final je me pose la question : est-ce que ça va me servir un jour, et est-ce que je perds pas du temps au final par rapport à simplement avoir tout ce qu'il faut installé en "local" sur un portable?
 
L'approche de jetbrains me semblait intéressante pour faire ça dans un style intermédiaire, avec un "client léger" qui va se connecter à un IDE qui tourne sur un serveur...mais quand j'ai voulu tester le truc était buggé à mort.

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).