Reprise du message précédent :

je saurais pas te chiffrer exactement, mais je me souviens d'une grosse requête sur Rankmill qui avait facilement gagné 5 secondes en virant le "*". je regarderais demain si je peux bencher ça

Ah.

Ouais.

OK.

T'avais 10.000 champs dans la requête, c'est ça?

edit: en fait c'est pas le fait de lister les champs explicitement au lieu de l'étoile qui ralentit ton bouzin, c'est que si tu commences à ramener tous les champs d'une requête multi-jointurée au lieu de prendre strictement que les champs dont tu as réellement besoin, forcément ça va prendre plus de temps avec un SELECT *

non, étron
juste pas mal de clauses where et un Sum() il me semble
 
je viens de faire le test sur une requête maison. un bête SELECT * sur une table comportant 9 champs et 166000 lignes (3 int, 3 bigint et 3 nvarchar(max)) => 754 ms
la même requête en nommant les champs => 112 ms
 
7 fois plus rapide, la messe est dite : SELECT * puxxor

c'est cross SGBD comme remarque, ou c'est propre à SQL server ?

Probablement différent suivant les sgbd, mais * est forcément moins rapide. Les chiffres d'harko m'étonnent, quand même.

Benchez-donc.

 
Oracle 10, table de 130K enregistrements environ, j'en retourne à peu près 11K :
 

<?php
 
$sql = "select * from adresse where cod_anu_ina = 2008";
$sql2 = "select adr_mail, cod_adr, cod_anu_ina, cod_bdi, cod_com, cod_ind,
            cod_ind_ina, cod_pay, lib_ad1, lib_ad2, lib_ad3, lib_ade, num_tel, num_tel_port
        from adresse where cod_anu_ina = 2008";
 
$user = "xxx";
$passwd = "xxx";
$base = "xxx";
 
$conn  = oci_connect($user,$passwd,$base) or die('erreur de connexion');
 
$start1 = microtime(true);
$stmt = oci_parse($conn, $sql);
$result = oci_execute($stmt);
$end1 = microtime(true);
 
echo 'étoile : ', $end1 - $start1, PHP_EOL;
 
$start2 = microtime(true);
$stmt2 = oci_parse($conn, $sql2);
$result2 = oci_execute($stmt2);
$end2 = microtime(true);
 
echo 'liste des champs : ', $end2 - $start2, PHP_EOL;

 
Pas de quoi s'énerver, quoi.

perso je ne pense pas que cela ait plus d'impact qu'éventuellement quelques accès supplémentaires au dictionnaire.
 
il faut faire gaffe avec des benchs consécutifs sur  les mêmes données, pour la 1ère requête il va faire ses i/o, alors que pour la 2ème utiliser la mise en cache des pages de la 1ère requête

Ouais enfin si tu benches pas les mêmes ça devient difficile de comparer, aussi.

Ben alors faut le faire trois fois, une fois pour ramener dans le buffer, puis tes deux séries de test.
 
ou dupliquer avant.

pour mon précédent bench d'hier soir, en fait j'ai reconstruit les indexes et updaté les stats, et j'arrive à 25 ms pour * et 21 ms pour tous les champs
 
bench plus rigoureux sous SQL Server à l'instant : sélection des 7 champs d'une view , constituée de 5 jointures. retourne 564 733 lignes
 
SELECT * : 743 ms
tous les champs :387 ms

Mes chiffres plus haut ont été reproduits plusieurs fois de suite.

Conclusion : SQL server == puxxor.

...faut pas déconner, ça revient juste exactement au même en interne pour le sgbd, il y a juste un replace de l'étoile par la liste des champs - laquelle ne doit pas prendre 400ms à remonter.

[edit - antiflood de mes 2 ]

...en fait avec une différence pareille tu irais plus vite à récupérer la liste des champs toi-même dans le langage client pour construire ta requête qu'à utiliser l'étoile, non?

sauf que là c'est une view, pas une table
laquelle view est constituée de 5 tables en INNER, dont 2 tables contiennent plus de 700 000 lignes
après, la tambouille interne du SGBD, j'tavouerais qu'elle m'est inconnue

ça revient au même...describe tavue ça remonte en 400ms?

C'est un cas super particulier, quoi

Merci, j'allais le dire
 
(en plus lui il travaille avec au minimum SQL Server 2005, moi chuis coincé avec SQL2K )

une autre requête (dans laquelle j'ai utilisé ROW_NUMBER pour simuler un DISTINCT => gain de 10 ms, c'est toujours ça de pris)
 

SELECT  *
            FROM    ( SELECT    Table1.champ,
                                toto,
                                Table2.titi,
                                Table2.cucu,
                                champ1,
                                champ2,
                                champ3,
                                MAX(Table3.champ) AS ts,
                                ROW_NUMBER() OVER ( PARTITION BY toto ORDER BY toto ) r
                      FROM TheTable2
                                INNER JOIN Table2 ON ...
                                INNER JOIN Table1 ON ...
                                INNER JOIN Table3 ON ...
                                INNER JOIN Table4 ON ...
                                INNER JOIN Table5 ON ...
                                INNER JOIN Table6 ON ...
                      WHERE     ( Table1.champ = 256 )
                      GROUP BY  
                Table1.champ,
                                toto,
                                Table2.titi,
                                Table2.cucu,
                                champ1,
                                champ2,
                                champ3
                    ) T
            WHERE   T.r = 1
            ORDER BY ts DESC

 
et la version "tous les champs" :

SELECT  champ,
                                toto,
                                titi,
                                cucu,
                                champ1,
                                champ2,
                                champ3,
                                                                ts,
                                                                r
            FROM    ( SELECT    Table1.champ,
                                toto,
                                Table2.titi,
                                Table2.cucu,
                                champ1,
                                champ2,
                                champ3,
                                MAX(Table3.champ) AS ts,
                                ROW_NUMBER() OVER ( PARTITION BY toto ORDER BY toto ) r
                      FROM TheTable2
                                INNER JOIN Table2 ON ...
                                INNER JOIN Table1 ON ...
                                INNER JOIN Table3 ON ...
                                INNER JOIN Table4 ON ...
                                INNER JOIN Table5 ON ...
                                INNER JOIN Table6 ON ...
                      WHERE     ( Table1.champ = 256 )
                      GROUP BY  
                Table1.champ,
                                toto,
                                Table2.titi,
                                Table2.cucu,
                                champ1,
                                champ2,
                                champ3
                    ) T
            WHERE   T.r = 1
            ORDER BY ts DESC

 
résultat : (Eval1 = tous les champs, Eval2 = *)
 

 
100 ms pour 365 lignes, c'est pas rien

La version avec étoile envoie 300octets de plus depuis le client? Quelqu'un saurait m'expliquer ça?

[edit]

oubliez, je lis à l'envers.

Pour rigoler, récupération de la liste des champs à la main avant :

<?php
 
 
$sql = "select * from adresse where cod_anu_ina = 2008";
$sql2 = "select adr_mail, cod_adr, cod_anu_ina, cod_bdi, cod_com, cod_ind,
            cod_ind_ina, cod_pay, lib_ad1, lib_ad2, lib_ad3, lib_ade, num_tel, num_tel_port
        from adresse where cod_anu_ina = 2008";
$sql3 =  "select * from adresse where 1=2";
 
 
$user = "xxxx";
$passwd = "xxx";
$base = "xxxx";
 
$conn  = oci_connect($user,$passwd,$base) or die('erreur de connexion');
 
$start1 = microtime(true);
$stmt = oci_parse($conn, $sql);
$result = oci_execute($stmt);
$end1 = microtime(true);
 
echo 'etoile : ', $end1 - $start1, PHP_EOL;
 
$start2 = microtime(true);
$stmt2 = oci_parse($conn, $sql2);
$result2 = oci_execute($stmt2);
$end2 = microtime(true);
 
echo 'liste des champs : ', $end2 - $start2, PHP_EOL;
 
$start3 = microtime(true);
$stmt3 = oci_parse($conn, $sql3);
$result3 = oci_execute($stmt3);
$columns = oci_num_fields($stmt);
$sql4 = 'select';
for($i = 1; $i <= $columns; $i++){
    $sql4 .= ' ' . oci_field_name($stmt, $i) . ',';
}
$sql4 .= '1 from adresse where cod_anu_ina = 2008';
 
$stmt4 = oci_parse($conn, $sql4);
$result4 = oci_execute($stmt4);
$end3 = microtime(true);
 
echo 'desc a la main : ', $end3 - $start3, PHP_EOL;

c'est chaud!

...mais c'est con en fait, je fais toujours un select *
Sortez moi.

[edit]

Avec le mode OCI_DESCRIBE_ONLY sur l'execution de stmt3 ça va mieux :

Ça change pas grand chose quand même

on va quasiment aussi vite quelle que soit la solution choisie...moi je dis que le sql server d'harko est moisi, c'est tout.

[edit]

Allez j'ai rajouté le fetchall pour voir si je me rapproche des résultats d'harko, on a un ordre de grandeur un peu plus significatif :

tu compares ce qui n'est pas comparable, je viens de faire un bête select d'une table de 14500 lignes et 5 champs, et j'obtiens :
* : 085 ms
tous : 082 ms
 
par contre, commence à mettre des jointures, des agrégats, ou mieux : fais un select * d'une vue séverement burnée (genre 5-6 jointures et tout le toutim), et poste tes résultats

Quelqu'un pour du Mysql et Postgres? J'ai pas Mysql ( et je compte pas l'installer ) et j'ai pas suffisament de lignes dans mes tables sous Postgres.

J'avais une db MySQL de taille conséquente mais faudrait que je la retrouve dans un backup
 
(et encore, j'ai pas de vue définie là-dedans)

 
Je trouve une vue avec moins de 40 champs à lister et je te fais ça.

euh mon exemple c'est 130000 lignes et 14 champs hein, ça reste plus significatif que ton truc.

Allez, avec une vue un peu plus couillue (jointure avec  notamment 4 tables ayant 45000, 62000, 80000 et 130000 lignes; 20 champs) :

$sql = "select * from extern_vue_mail_etudiant";
$sql2 = "select adresse_acheminement, adresse_code_postal, adresse_ligne_1,
        adresse_ligne_2, adresse_ligne_3, adresse_ligne_etranger, adresse_pays,
        cle_activation, cod_etu, date_naissance, genre, ine, nom_patronymique, nom_usuel,
        prenom_1, prenom_2, prenom_3, telephone, temoin_ine_provisoire, universite
        from extern_vue_mail_etudiant";
 
$user = "xxx";
$passwd = "xxx";
$base = "xxx";
 
$conn  = oci_connect($user,$passwd,$base) or die('erreur de connexion');
 
$start1 = microtime(true);
$stmt = oci_parse($conn, $sql);
$result = oci_execute($stmt);
oci_fetch_all($stmt, $all);
$end1 = microtime(true);
 
echo 'etoile : ', $end1 - $start1, PHP_EOL;
 
$start2 = microtime(true);
$stmt2 = oci_parse($conn, $sql2);
$result2 = oci_execute($stmt2);
oci_fetch_all($stmt2, $all2);
$end2 = microtime(true);
 
echo 'liste des champs : ', $end2 - $start2, PHP_EOL;

Première exécution :

Deuxième exécution :

La mienne est plus grosse que la vôtre  

Bon, j'vais jouer à votre jeu en SQL Server 2000, j'en ai une pas trop mal pour ça

Je peux pas utiliser mes plus grosses tables, ça crashe php.
Faudrait que je trouve comment on mesure le temps d'exécution directement dans toad.
'fin de toute manière ça devrait être fonction du nombre de champs à retourner, pas de la taille de la table.

Ouais pareil, parce que j'ai que le temps en secondes
 
ptet que SELECT GETDATE() avant et après le ferait

Tiens pendant que j'y pense, j'aurais besoin en sql de récupérer un BLOB venant d'une autre base (les 2 bases sont sous oracle 10).
Les blob ne passant pas avec un dblink, quelqu'un aurait une solution sympa? La seule option que je vois c'est de se connecter à l'autre base dans une fonction, mais je trouve casse-pieds de devoir mettre un login/mot de passe en clair là-dedans...

Tiens, et autre question à la con. J'ai un fichier PHP en utf8, je veux interroger une base oracle en iso8859.
La requête que je veux exécuter fait grosso-modo ça :
 

SELECT 'une chaine avec accent éééé' || unchamptexteavecdesaccents FROM TABLE

 
Problème : si j'utilise la requête telle quelle dans mon fichier php, dans le résultat obtenu les accents de la chaine concaténée "en dur" sont codés en utf8, et ceux venant du champ dans la base en iso8859.
Quelqu'un a une solution propre pour ça?

http://php.net/manual/en/function.utf8-decode.php
 

SELECT 'une chaine avec accent éééé' || unchamptexteavecdesaccents FROM TABLE

 
Peut être en renseignant la variable NLS_LANG: + propre que d'encoder décoder à chaque fois.

Je me demande ce qui est le plus moche entre

$sql = "SELECT '" . utf8_decode('une chaine avec accent éééé') . "'|| unchamptexteavecdesaccents FROM TABLE";

et (solution adoptée pour l'instant) :

$sql = "SELECT convert('une chaine avec accent éééé', 'WE8ISO8859P1', 'UTF8') || unchamptexteavecdesaccents FROM TABLE";

raté, essaye encore C'est déjà fait, ça, et heureusement.
Curieusement - ou pas, quand on connait le bestiau - renseigner les bonnes variables d'environnement et spécifier le jeu de caractères à utiliser ne suffisent pas à php pour se démerder tout seul.

question postgis/postgresql :

SELECT 
   "groupement",
    encode(AsBinary(force_collection(force_2d("the_geom" )),'NDR'),'base64') AS geom,
   "gid" 
FROM (
         SELECT 
               c1.the_geom AS the_geom, 
               c1.gid AS gid ,
               c1.groupement 
         FROM commune AS c1 
             JOIN thematique AS t ON c1.gid =t.gid
        ) AS foo

ça marche en direct dans la console sql , ça ne marche pas depuis une appli (ERROR: relation "thematique" does not exist )

des idées ?