Reprise du message précédent :
Par ailleurs, si t'as enchaîné     SELECT *  
    FROM majolietable
    WHERE id= majoliefonction(32);
 
et     SELECT a.*  
    FROM majolietable a
          JOIN (SELECT majoliefonction(32) id FROM dual) b ON b.id=a.id;
 
Je pense que le cache a été utilisé. T'avais vidé tous les caches entre les 2 ?
 
En effet, comme pas mal de gens utilisent le where pour faire les équi-jointures, pas mal d'optimiseurs de requêtes font la transfo pour mettre les conditions dans le JOIN... ON.

Parce que RTFM il me semble
Le retour de ta fonction dépend de la ligne ?
Si non, t'as essayé de la mettre dans une variable ?

    SELECT * FROM majolietable WHERE id = 34   --> 150 ms donc utilisation de l'index
 
    SELECT *  
    FROM majolietable
    WHERE id= majoliefonction(32);  --> 58s donc pas d'utilisation de l'index
 
J'aurai tendance à penser que ça vient du côté dynamique de la fonction : l'optimiseur de requête ne peut pas prédire le résultat de la fonction, donc ignore la quantité d'enregistrements qui va correspondre et donc si c'est pertinent de passer par l'index ou pas (ou alors il fait peut-être une mauvaise éval). Alors qu'avec une constante, il sait faire cette éval qui est bonne.

 
non, la différence n'a rien à voir avec les caches.
Effectivement dans la version avec l'appel de fonction il fait un full scan comme un gros bozo, alors qu'avec la valeur en dur il utilise l'index.
Dans la version avec jointure sur la sous-requête il fait bien le découpage en deux opérations, donc utilise l'index pour faire la jointure.

 
Ah ça c'est fort probable, il m'est jamais venu à l'idée que les absurdités apparentes de mysql puissent être documentées.
 

 
Non, pas essayé. Je voulais juste écrire une petite requête simple vite fait pour vérifier que ma fonction fait bien ce qu'il faut, en fait, là...

SELECT a.* 
FROM majolietable a
      JOIN (SELECT majoliefonction(32) id FROM dual) b ON b.id=a.id;

Tu devrais essayer :
 

SELECT *
FROM majolietable
WHERE id = (SELECT majoliefonction(32) FROM dual);

Je suis même pas sûr que t'ai besoin du "from dual" (t'as fait de l'Oracle non avant ? )

SELECT *
FROM majolietable
WHERE id = (SELECT majoliefonction(32) id FROM dual);

Non celle-ci donne le résultat débile aussi, c'est la première que j'ai tentée pour essayer de contourner.

Tiens, 2articles intéressants sur l'optimiseur de requêtes de Mysql :
https://www.informit.com/articles/a [...] 2&seqNum=2
 
Et doc du fonctionnement interne de l'optimiseur :  
https://dev.mysql.com/doc/internals [...] -code.html

Ben si, parce que tu peux dire "voila, j'en ai fait 10 aujourd'hui", c'est plus motivant et plus  gratifiant que dire "je sais pas combien de temps je vais mettre encore pour ces 2000 lignes", et à la fin t'en as marre et tu bâcles le truc juste pour dire "j'ai fini".

J’ai fini par l’avoir, mais le bouchon était dans un coude à environ 12m de l’évier, autant dire que la ventouse ne faisait pas grand chose.

Acide sulfurique. Le problème c’est que la réaction avec l’eau dégage assez de chaleur pour faire fondre les tuyaux.

 
J'éviterais d'enchaîner un acide et une base forte dans le même tuyau bouché pour éviter un échauffement prononcé voire un dégagement de gaz chloré extrêmement toxique.

 
 
(mais genre le napalm ne vous a pas mis la puce à l'oreille ? )

 
Mais enfin comment veux-tu employer du napalm dans ta cuisine en toute sécurité si tu t'es intoxiqué au chlore avant ?    

pour un mec de 59 piges il touche un peu à la batterie, quand meme
https://www.youtube.com/watch?v=FssULNGSZIA
 
 
débarquement de l'espace mais je découvre Tool et ça déboite. C'est comme Dream theater, mais sans le chanteur à la voix de chat écrasé

SELECT majoliefonction(32) FROM dual;

SELECT * FROM majolietable WHERE id = 34

SELECT * 
FROM majolietable
WHERE id= majoliefonction(32);

Ben ça c'est tout à fait normal et ça serait pareil sur tous les SGBDR.
 
Le 1 ne fait qu'un calcul (avec la syntaxe moisie du SQL).
Le 2 fait une requête standard sur une table indexée.
Le 3 fait une requête avec le résultat d'une fonction donc typiquement pas indexable donc il passe sur un scan.
Si ta fonction retourne un entier, dans ce cas tu as intérêt à faire le calcul, le stocker dans un entier, et faire la requête sur cet entier.

 
La batterie n'est pas une question de force (enfin sauf quand on est très mauvais, qu'on débute et qu'on ne pense qu'à faire du bruit), c'est une question de technique avant tout. Le fait d'avoir 59 ans ne change strictement rien du tout (enfin sauf si ce mec vient d'apprendre à jouer de la batterie, auquel cas, il aurait de supers capacités d'apprentissage pour un mec de cet age).
Je sais que plein de batteurs ont des muscles, et c'est vrai qu'être batteur fait travailler les muscles, mais c'est la plupart du temps parce que ça correspond aussi à leur look et leur mode de vie.
Enfin bref, c'est un bon batteur et le fait qu'il ait 59 ans n'est absolument pas impressionnant.  
 
Ce qui impressionant, c'est ça :
 
https://www.youtube.com/watch?v=zXl [...] u.be&t=203
 
Arthur Rubinstein - The Last Recital for Israel, 1975 (Beethoven, Schumann, Debussy, Chopin)
 
à 87 ans...    
 
Et pour jouer beethoven, il faut largement autant de force physique que pour faire de la batterie, mais si on ne s'en rend absolument pas compte... On va dire qu'en plus, il faut énormément d'autres capacités que j'ai pas le temps d'énumérer.
 
Là, oui, on peut dire que "pour un mec de 87 ans", il touche un peu du piano cômême.  

...et donc le sgbd a aucun moyen de déterminer ça tout seul comme un grand?
 
Faut que je fasse le test avec oracle, tiens...

Parce que les retours de fonctions ne sont pas typées ou typées NUMBER ?

returns int...

Sans vouloir faire un concours de celui qui a la plus grosse, je pense que Mike Terrana (60 ans, batteur, entre autres, de Tarja Turunen) est meilleur dans ce solo de malade : https://www.youtube.com/watch?v=efXGNwJ0SVI  

Généralement les fonctions des barrières d’optimisation, sauf si elles sont annotées. Dans Postgres les fonctions dont annotées / classifiées immutable, stable ou volatile.  
 
Si une fonction est immutable (= pure) pg va probablement pouvoir l’optimiser, stable (va lire la db) peut-être selon le contexte, mais volatile (la valeur par defaut) certainement pas.
 
La doc note qu’une fonction immutable est traitée comme une constante à l’échelle de la query, une stable peut être utilisée dans ke cadre d’un index avance et une volatile est nécessairement réévaluée dans tous les contextes donc c’est du full scan dans tous les cas.
 
pg12 ajoute des support functions qui permettent de s’intégrer avec divers contextes d’optimisation.
 
Après peut-être que dans oracle les fonctions ne sont pas des barrières.

 
J'essaierai de prendre le temps de tester, par curiosité. En tout cas vu la quantité de trucs d'opti hyper complexes que font les SGDB, savoir traiter un variableInt = fonctionRetourneInt() comme un variableInt = const me parait incroyablement simple...

https://www.20minutes.fr/monde/2784 [...] de-ampleur

Les musiciens ça ne vieillit pas trop, ou très tard. Rubinstein, Horowitz, Arrau, ils mettaient encore une pilée à bon nombre de pianistes même sur le tard.
Sinon écoute le dernier récital de Lipatti. Il n'était pas vieux mais gravement malade au point de ne pas pouvoir jouer la dernière valse de Chopin, et de mourir 2 mois et demi plus tard.

Traiter rand() ou newid() comme une constante est simple mais je doute que ce soit très correct.

 c'est une question de préférence : il joue bcp plus vite, mais je trouve pas pour autant ça mélodieux ou intéressant...la double pédale à 200bpm bien tenu c'est surement très difficile à réaliser, j'ai vraiment jamais trouvé que ça amenait grand chose (souvent sur une batterie ça va couvrir les autres parties)
En guitare c'est pareil, tu vas avoir Eric Johnson, Clapton, Knopfler, Gilmour pis en face tu vas avoir je sais pas moi , Malmsteen. Il joue bien plus vite que les précédents. Je suis pas certain qu'il joue "mieux".

comme un critère de jointure alors si tu préfères.

(...mais vu d'ici ça change rien, tu lookup un int dans un index, la manière de générer l'int en question avant ça n'est pas terriblement pertinente)

Sauf que la encore c’est pas correct si ta fonction a des effets de bord tels que sa valeur change à chaque invocation.  
 
Tu vas me dire que c’est stupide d’utiliser une telle fonction, et c’est vrai, mais c’est légal donc ça doit marcher comme ça

bon avec le shitstorm de strava c'est le bon moment pour ressortir trainoo  

par contre au niveau création c'est pas terrible en vieillissant  

Ca dépend, y'a plein d'artistes dont les oeuvres les plus importantes ou les plus visionnaires sont celles de la fin.

 
non mais pourquoi ton plan d'exec serait pas systématiquement ça dans un cas pareil :
1) calcul du résultat de la fonction
2 ) lookup du résultat dans l'index
 

Ca marche quoi qu'il se passe dans ta fonction, a priori...

Le traitement de la requête fait que peut-être, l'optimiseur travaille dans un ordre différent. En général, il essaye d'avoir le moins de lignes à traiter ce qui va déterminer le choix de l'index ou des index à utiliser. Dans le cas du id = const, il sait le déterminer. Dans le cas de id = résultatfonction(), il ne sait pas le nb de lignes que ça va faire tant que la fonction n'aura pas été exécutée. Or, dans sa façon de procéder, si y'a une fonction, l'index n'est généralement pas utilisé.

 
Il y a des exceptions. Par exemple Rameau, qui a commencé à écrire des opéras sublimes à 50 ans.    Mais c’est vrai qu’en général, l’âge n’est pas toujours un plus pour créer.

Comme chaque année a la même période , ça commence a être dur , désolé si je suis désagréable

Encore un mois a tenir avant l'anniversaire d'erwan

Vous connaissez ? https://www.youtube.com/watch?v=aQ0yOmtl96A
 
Moi qui avait l'âge de regarder Saint Seiya au moment où ça passait au Club Dorothée, ça me fait trop marrer

Courage mec...

. Tout à l'heure moment auto analyse : il y a un lien avec le fait  je sois autant agacé par les gens qui se plaignent du confinement avec leurs enfants et de la (non) reprise de l'ecole.
Le temps passé avec ses enfants n'est pas perdu

la team choloroquinine prends bien cher au passage , un peu comme prévu