Reprise du message précédent :

Il est dedans, genre ligne 11.

Rien tuné du tout, et requête générée par doctrine...j'obtiens de meilleurs résultats en faisant un select normal et un count() du résultat en php...

[edit]

Requête bien plus complexe que montré, avec des tables de plusieurs centaines de milliers de lignes...mais le résultat est débile quel que soit le contexte.

Je sais que Postgres a / a eu le même problème parce que l’optimisation sait/savait faire des agrégats pour select distinct mais se tapait un seq scan pour count(distinct).
 
Le workaround c’était de select count(*) from (select distinct …)  
 
Edit: issue 21849 de MySQL, apparemment amélioré dans 5.5.0 donc si t’as un vieux mysql…

https://www.tftcentral.co.uk/blog/a [...] -hdr-1400/

   
Donc autant dire qu'avec le COVID-19 ça risque de devenir Q4 2020 ou H1 2021

je suis halluciné de l'inflation sur le prix des écrans.
 
Mon écran actuel était un Asus ProArt PA329Q 32" 4K que j'avais payé 1399.- CHF, soit ~1160£. Le nouveau (certes LED QDOT, FALD) coute 2108£

Yo,

J'ai vu il y a quelques temps que ça parlait de shadow pc ici... Ça vaut le coup ce truc ?
Parce que vu de loin, on dirait qu'il faut 10 ans pour rentabiliser un PC gaming construit à la main comme autrefois par rapport à un abonnement annuel à ce service.

Vraiment? Avec un Ryzen 3300X et une RX 5500 il doit y avoir moyen de jouer à quasiment n'importe quoi en FHD.

2100£ ici... et pis je suis pas forcément chaud pour reprendre un ProArt, c'est un ProArt qui vient de me lacher
 
Pour lesNum le comparo est très orienté budget, et recommander le Samsung c'est un peu LOL : le truc utilise encore un backlight PWM
 

vrai, mais je pense que ce sera sans, si je filtre là dessus il reste 2 écran
 
ça semble se jouer entre un 27" QHD (LG 27GL850) ~450£, et un 34" wide QHD (LG 34GK950F) ~1500£...les 2 étant Freesync 2 et donc aussi compatible G-Sync, 144Hz.
Ça fait chier parce que c'est pas le bon moment pour acheter, dans pas trop longtemps on devrait avoir plus d'écrans QDot disponibles, et on peut aussi penser que le mini-led arrivera bientot vu que ça se generalise sur les télés.
Edit : lol amazon, en l'achetant chez Currys (une sorte de Darty local) il est à 948£
 

Juste le cpu et la cg que tu cites, y en a pour quasi 500 balles. Ajoute la ram, la carte mère, une alim et un boitier (dans mon cas ceux que j'ai ne sont pas récupérables)... Et même sans hdd/sdd, écran, clavier et souris, ben qques années d'abonnement à un shadow pc semblent plus intéressant.
Je me trompe ?

je dirais que ça mérite réflexion.
 
Mandatory Linus tech tips sur le sujet : https://www.youtube.com/watch?v=d3dNoCRzbAs
 
Le type de jeu d'abord : si tu joues à des FPS, le lag sur ce genre de système est encore perceptible
Le catalogue : est-ce que les jeux que tu veux sont dessus ?
Quel temps tu passes réellement à jouer ?  
 
faut bien regarder les offres.

La RX 5500 XT 4Go devrait se trouver à partir de 200€ quand y aura plus de références disponibles en stock.

Un desktop avec des composants un minimum modernes (quad-core, suffisamment de RAM et SSD, boîtier et alim silencieux) c'est quand même sympa si tu fais pas que jouer.
À partir de là, le coût marginal pour pouvoir jouer en FHD est raisonnable.

Après oui si tu veux garder un vieux PC, Shadow a l'air pas mal.
Mais sur le cycle de vie d'une petite config montée aujourd'hui, t'arrives facilement à plus de 600€ d'abonnement.

Je viens de lancer un print 3D de 32 heures, estimé à 225 grammes de PLA. A vue de nez, la bobine arrive sur la fin et si ça passe, ça tombera vraiment pas loin
 
**serre les fesses**

/jyconnaisrien
 
Il peut pas pause et resume une fois que tu as changé la bobine?
 

 
Je suis vraiment pas sur qu'ils soient rentable pour être franc, le cout en datacenter + l'elec + la config j'ai du mal a voir comment ils arrivent a être rentable... Donc je suppute une augmentation des tarifs un jour... Ca ressemble a une espèce d'offre de lancement...
 
Même chez les "petits" provider de ce genre d'offre (pour du tensorflow par exemple) j'ai jamais vu sous la barre des 100e/gpu/mois pour une 2080 ou supérieur...

 
Nope, c'est une 5.7.
Je vais tente le workaround quand même pour voir tiens.

Attention au nb de tables ouvertes et surtout aux tables temporaires qui sont très couteuses en Mysql. T'as fait un EXPLAIN de ta requête pour voir quels index il utilise ? S'il faut, il utilise pas ceux que tu crois et tu peux lui forcer les index à utiliser (using) pour être plus optimisé.
 
T'as essayé avec group by ?

Oui, c'est via ce comparatif que j'ai trouvé l'écran. Je voulais dire que c'est dommage qu'on puisse pas filtrer sur le type de connectique "TB". Y'a HDMI, DVI, YUV mais pas TB

Intéressant.
Du coup on peut arguer que ça peut valoir le coût d'en profiter tant que c'est à ce prix-là.
Et réévaluer ensuite si ça change.

Je ne suis pas attaché à un quelconque vieux pc.
Par contre ce ne serait que pour jouer : j'ai un laptop de compétition pour le taf (quad core, 16Go de ram, ultra portable...), mais pas adapté pour le jeu (cg de merde, normal sur ce genre de bécane). Je kiffe ce laptop, et un shadow me permettrait de jouer sur ce laptop (leur client existe sur linux en plus), et j'avoue que je trouve l'idée séduisante.

Maintenant, pour ta remarque, je sais pas... 5 ans c'est long pour une config. Mon actuelle a 6 ans et je oeux probablement jouer aux jeux actuels... Tout au minimum, et si le moteur est bien foutu. Et pas tous (y en a que je peux pas espérer lancer). Je pense que ça tient, mais comme c'est que pour du gaming, le ROI me semble pas évident.

Toute chose égale par ailleurs évidemment : il faut que la latence se sente pas ou peu même en période de pointe, par ex.

Je joue très rarement à des fps mais c'est une bonne remarque. Pour le catalogue c'est une vm win10 donc le catalogue c'est moi qui l'apporte

Merci pour ces quelques retours... Ça vaut peut-être le coup de prendre le truc quelques mois pour tester et réévaluer la situation ensuite.

SELECT DISTINCT bidule FROM [...]

SELECT count(DISTINCT bidule) FROM [...]

Je donne pas de conseils MySQL sans les Explain

 
Normalement si tu peux

 
le explain est identique à la version sans count, et ça utile les indexes disponibles. Et il y a bcp de jointures, oui...mais c'est pas comme si j'avais le choix.

Normalement avec un détecteur de fin de filament, si, mais mon imprimante n'en est pas équipée. Ça fait partie des améliorations que je compte rajouter.
Je peux surveiller la bobine, et mettre l'imprimante en pause une fois qu'elle est finie pour la changer, mais je n'ai plus de filament de la même couleur  

Ca vaudrait le coup d'augmenter les variables de conf en rapport avec le nb de tables qui peuvent être ouvertes en mémoire et sur la taille des tables temporaires en mémoire.
Après, si la requête est vraiment trop grosse, ça vaudrait peut-être le coup de faire soit une vue soit de précalculer certains données dans une ou plusieurs tables qui seront mises à jour à certains moments (périodique ou à chaque opération C/U/D).
 
Edit : si t'as de la latitude, voir si en changeant certains index, ça améliore le délai.

Les délais quand même pour Shadow

600€ de Shadow ça fait 4 ans, pas 5.
Une config de 2016 qui faisait tourner les jeux en FHD à l'époque le fait probablement toujours aujourd'hui.
Y a eu des évolutions niveau prix sur les CPU grâce à AMD, sur les GPU c'est déjà moins évident, et les perfs ont pas énormément évolué.
 
Perso j'aimerais bien pouvoir bosser sur un PC pour le boulot, tellement mon laptop chauffe et ventile.

Après comme l'a dit Jubi, le vrai truc à regarder c'est surtout tes jeux aussi. Si t'es un casu, aucun soucis. Mais les FPS compétitif ou les jeux de Blizzard par exemple, c'est mort.

Et aussi regarder tes exigences en qualité. Perso garder une config 6 ans pour jouer en FHD en moyen sur des triples A, ca m'interesse pas du tout.

On a une nouvelle génération de consoles qui débarque sous peu. Les jeux qui vont être faits pour l'exploiter correctement vont aussi probablement augmenter la machine mini qu'ils visent sur PC.

Les deux grosses machines à venir ayant 8C/16T sur des CPU à plus de 3.2GHz, quelqu'un qui veut une machine qui va durer 5 ans devrait miser au moins sur ca, sinon, c'est un coup à se retrouver avec une machine obsolète dès la fin de l'année.

Autant le GPU peut toujours fonctionner en se limitant à des résolutions (parfois juste de rendu) inférieures (ou avec des tech de résolutions dynamiques parce que ca a l'air de bien se répandre), autant la charge de travail côté CPU est plus dure à ajuster par le jeu.

Edit : Et jouez aux jeux de cowboy dans le bayou en multijoueurs !!

Pas de vues possibles (ou alors en se faisant méchamment chier), c'est de la requête créée dynamiquement...
Bref, je vais probablement remanier la méthode de génération de la requête , à coups de sous-requêtes au lieu de jointures sur certaines grosses tables ça semble plus performant au final...

...mais c'était pas le point. Juste que mysql est naze à être infiniment plus lent à faire le count qu'à renvoyer tous les résultats.

Je suis étonné, j'ai pour l'instant jamais rencontré ce pb autant que je m'en souvienne. Je bosse avec depuis 2003, MySQL 3.23, qui n'avait pas les sous-requêtes, comment je galérais pour certaines requêtes : obligé de passer par des tables temporaires. J'ai été très content quand les sous-requêtes sont arrivées à partir de Mysql 4.
 
UN SGBD bien pourri : Firebird ! C'est un fork d'Interbase. Y'a très peu de types de données, peu de fonctions, pas de sous-requêtes sur la v1.5 (c'est celle qui est utilisée par le logiciel de gestion en place). Le mec qui a fait ce choix de SGBD (2006) ...    

Sinon, vous avez vu les nouveaux Surface Book ?

Putain je découvre ce mec, c'est un génie
https://twitter.com/beeple

J'ai fait des tests pour mes bases avec mysql puis plus récemment postgresql, finalement pour certains traitements ça m'a saoulé et j'ai exporté et fait les traitements moi-même.  
Ce qui m'a le plus dérangé c'est que les traitements étaient longs (mais vraiment très, plus d'une journée parfois) une fois sur deux.
Bon c'était très volumineux, des tables de dizaines de millions de lignes.
Bon faut dire qu'on fait les malins à faire tourner sur des PC moyens des bases qui avant tournaient sur des gros SUN.

Putain les mecs, vous savez que ce forum avec ses millions d'enregistrements tourne sous MySQL et fonctionne quand même pas trop mal non ? (au moins au niveau accès BDD)
 
Z'êtes surs que c'est pas un PEBCAK ?

@Harkonnen:  
Je suis sûr qu'il y aurait eu un moyen et que j'étais partiellement le problème oui. Ma «science» elle s'arrête à comprendre les explain plan, je ne suis pas DBA et ne dispose pas de journées pour comprendre le paramétrage fin, donc si j'ai dans mon chapeau une autre méthode qui fonctionne et que je connais, je n'attends pas trop longtemps  
Surtout que je n'ai pas le luxe de faire ça en développement, en général j'ai des clients qui attendent des résultats de traitement derrière, toujours, et souvent pour hier, et je suis tout seul pour tout (on a cinq bases de données principales et on propose beaucoup de traitements, standards pour ceux qu'on essaie de faire comme produits mais aussi beaucoup à la carte, pour qu'un client puisse rentrer les données achetées ou calculées dans sa base existante etc.).
 
Donc j'ai essayé de faire quelques bidouilles sur les mémoires allouées et j'ai vite abandonné parce qu'au niveau temps j'allais dans le mur.
 
Et pour ça je n'avais pas besoin d'une base, pas d'accès concurrents, mais des traitements sur de grosses jointures pour la totalité des données ou plus souvent une partie (avec clé + matchcode pour analyser les variations sur nouvelles données fournies en totalité pour y reporter tout un historique).

Des dizaines de millions d'opérations (c'est à dire? select/jointure ou ?), ça devrait rester de l'ordre de la seconde avec des index.

Par exemple pour les plus gros traitements, remplacement de 30 millions d'enregistrements de façon sélective avec 30 millions de nouveaux en entrée mais qui n'ont pas toujours changé.
Selon ce qui a changé, adresses, valeurs des critères etc., on recolle ou pas certaines données de certaines autres tables ou on les supprime ou bascule dans des historiques.
Pour certains enregistrements on doit aussi recalculer des choses (par exemple si l'adresse postale a changé je dois repasser en RNVP (restructuration normalisation validation postale)).
En général si les index sont déjà construits ça ne passe pas car il y a trop de changements sur les données, il vaut mieux les détruire et les reconstruire après.
C'est souvent plus rapide de splitter une table en plusieurs tables temporaires (selon données qui changent ou pas) puis la reconstituer après.

Une différence c'est qu'un forum même si ça a pas mal de données en quantités c'est du requêtage généralement assez simple, d'autant plus si tes index sont pas trop mal foutus.

Si t'es joueur et que tu pars du principe que supprimer des commentaires en début de gros threads c'est super rare, tu peux même annoter chaque commentaire avec sa page (me demande si hfr fait pas ça d'ailleurs vu les liens de quotes & autres tout pêtés quand tu remontes dans les vieux commentaires ici, avec les ceux qui supprimaient leurs commentaires pour IWH).

 
C'est pas exactement le même type de requêtes que ce que je fais là, a priori.
Et je vois pas comment le problème que j'avais mentionné peut être un pebkac.

C'est bien que vous discutiez de Shadow, je me pose les mêmes questions et j'ai la flemme de réfléchir au truc

Flo 1- 0 Webpack \o/

Cet outil a été conçu pour filer des crises de nerfs aux devs peu habitués, je pense.

oui et non. Sans un outil comme ça, je ne pourrai pas faire ce que je fais (cross compilation pour ios/android/web)  
Mais forcement, les outils qui masquent la complexité te la font payer quand tu dois mettre les main dedans
Et il la font payer cher

(en vrai le score  à plutôt été 396 - 395 )