SELECT CONCAT( etb_id, '-', ofr_id ) AS code, COUNT( DISTINCT CONCAT(
etb_id, '-', ofr_id ) ) AS count
FROM radacct, card
WHERE card.card_username = radacct.UserName
GROUP BY UserName
HAVING MIN( AcctStartTime ) LIKE '2007-01-10%'
sur MySQL 4.1, j'ai déjà observé qu'il y avait une explosion de mémoire (et temps) pour une jointure alors que la taille du résultat ne le justifiais pas...
Du coup, j'ai procédé moi même au découpement de la requête en Java (JDBC), ce qui avait donné lieu à de vives critiques lors d'un fil précédent.
Je ne dis pas qu'un autre SGBDR aurait fait la même chose, mais je dis qu'une jointure ca coute cher...
A priori, ca coute au moins - R x log(S) ou S est la table référencée (CIR ou s'il y a un index sur le bon attribut de S), - ou R x S s'il n'y en a pas...
(en supposant R et S deux cardinalités des deux tables mise en jeux).
Sinon, je demande à ce qu'on m'explique l'algo miraculeux ?
oui une jointure est très coûteuse en temps tu viens de découvrir une des raisons des performances des SGBDR MV moins de jointures
par exemple voici un test sur un duron700 (une machine la plus faible que j'ai trouvé avec HD déplorable 128mo ram .....) de openqm
la requête lancé pour le test contient la gestion de 90 items et l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué (en SQL il aurait fallu 63 tables)
Pif a écrit :
sur MySQL 4.1, j'ai déjà observé qu'il y avait une explosion de mémoire
(et temps) pour une jointure alors que la taille du résultat ne le
justifiais pas...
Du coup, j'ai procédé moi même au découpement de la requête en Java
(JDBC), ce qui avait donné lieu à de vives critiques lors d'un fil
précédent.
Je ne dis pas qu'un autre SGBDR aurait fait la même chose, mais je dis
qu'une jointure ca coute cher...
A priori, ca coute au moins
- R x log(S) ou S est la table référencée (CIR ou s'il y a un index
sur le bon attribut de S),
- ou R x S s'il n'y en a pas...
(en supposant R et S deux cardinalités des deux tables mise en jeux).
Sinon, je demande à ce qu'on m'explique l'algo miraculeux ?
oui une jointure est très coûteuse en temps tu viens de découvrir une
des raisons des performances des SGBDR MV moins de jointures
par exemple voici un test sur un duron700 (une machine la plus faible
que j'ai trouvé avec HD déplorable 128mo ram .....) de openqm
la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
sur MySQL 4.1, j'ai déjà observé qu'il y avait une explosion de mémoire (et temps) pour une jointure alors que la taille du résultat ne le justifiais pas...
Du coup, j'ai procédé moi même au découpement de la requête en Java (JDBC), ce qui avait donné lieu à de vives critiques lors d'un fil précédent.
Je ne dis pas qu'un autre SGBDR aurait fait la même chose, mais je dis qu'une jointure ca coute cher...
A priori, ca coute au moins - R x log(S) ou S est la table référencée (CIR ou s'il y a un index sur le bon attribut de S), - ou R x S s'il n'y en a pas...
(en supposant R et S deux cardinalités des deux tables mise en jeux).
Sinon, je demande à ce qu'on m'explique l'algo miraculeux ?
oui une jointure est très coûteuse en temps tu viens de découvrir une des raisons des performances des SGBDR MV moins de jointures
par exemple voici un test sur un duron700 (une machine la plus faible que j'ai trouvé avec HD déplorable 128mo ram .....) de openqm
la requête lancé pour le test contient la gestion de 90 items et l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué (en SQL il aurait fallu 63 tables)
