Forum Programmation.SQL FETCH : comment sa marche ?!!!

Posté par  .
Étiquettes :
0
30
juin
2008
bonjour,



À travers certaines mesures expérimentales sur les bases de données dans mon boulot ; j'ai pu constater l'énorme lenteur de la commande FETCH (NEXT).

je travail sous postgreSQL v8.2.

J’ai écrit un programme en ECPG dans lequel je devais poser une requête Q1 et récupérer son résultat qui est un ensemble de ligne. Grâce à un curseur je parcourrai ce résultat et effectué un certain traitement sur chaque ligne.

Ma première implémentation utilisée la commande FETCH NEXT afin de passé d'une ligne à une autre. J’ai constaté un énorme écart de temps d'exécution entre le fait de récupérer directement toutes les lignes de Q1, les stockés en mémoire dans une structure de données que le fait d'utiliser la commande Fetch Next. La commande FETCH NEXT à elle toute seul comptabilisée 95% du temps d'exécution.

Face à une base de données importante il est clair que ça serai impossible de tout charger dans la mémoire ; je me suis donc mis à chercher une solution sur le Web. À travers ma recherche j'ai pu constater que ce problème ne se pose pas uniquement sur postgresSQL, mais sur la plus part des bases de données.

J’ai trouvé certains post qui préconisé de charger par bloc grâce à la commande FETCH FORWARD au lieu de ligne par ligne (FETCH NEXT). En expérimentant cette approche, j'ai pu constater des améliorations non négligeables, de l'ordre de 70 à 95 % (waw).

Mais alors pourquoi je poste ce message ?

La réponse est simple : POURQUOI !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Pourquoi la commande FETCH (NEXT) est aussi lente quand on lit ligne par ligne ? Cette question selon mon raisonnement nous renvoie à son implémentation ; au principe même de cette commande.

Je me tourne donc vers vous pour vous demander une explication. Et surtout savoir comment ça marche.

Merci d'avance.

PS : Tout document ou schéma expliquant le principe est le bienvenu.

  • # Pas de titre cette fois

    Posté par  . Évalué à 2.

    Il me semble que dans bien des implémentations, fecth effectue la requête complète à chaque fois et ne retourne que la x-ième ligne. Donc le serveur n'a à stocker que le compteur de lignes.

    Pour tester cela j'avais effectué des fetch sur une liste triée avant et après modifications. C'était avec un vieux SQL server. J'avais constaté que les dernières données retournées correspondaient aux dernières données modifiées. Ce qui est éventuellement le comportement voulu, je ne sais pas.

    Peut-être que certaines implémentations font que fetch forward stocke les données. Et tous cas, ce n'est pas une optimisation portable :-)

    • [^] # Re: Pas de titre cette fois

      Posté par  . Évalué à 1.

      Je me suis amusé entre temps à mesurer le temps d'exécution d'une requête Q1 avec et sans indexe sur au moins un critère de la close WHERE de Q1.

      Je pensais qu'en mettant un indexe sur un des critères de Q1 j'améliorerai le temps d'exécution de la commande FETCH, mais ils n'ont n"ai rien. Il apparait que seul un scan séquentiel est admis. Aucune optimisation par la prise en compte des indexes n'est autorisée!!!!!!

      Je suis vraiment curieux de savoir comment un Curseur ainsi que FETCH marchent (le principe de base au moins).

      • [^] # Re: Pas de titre cette fois

        Posté par  . Évalué à 1.

        y'a t'il un moyen de fair en sorte que le curseur laisse les données en mémoire et à chaque exécution de la commande Fetch qu'il ne fasse que les lires ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.