Paging optimisé Oracle

Bonjour,

Nous avons implémenté un système de paging basique, comme décrit dans la plupart des docs Oracle, sous forme d'inline views. Mais je trouve ça assez couteux et pas très efficace :-/ à part renvoyer un ResultSet plus petit ça n'allège pas vraiment le boulot du serveur DB.

Après avoir parlé avec un copain, je me demandais si faire un truc du genre ne serait pas plus efficace:

Code:

---

1 2 3 4

select * from TestTable where col > lastPreviousReturnedCol and rownum < 15 order by col   où lastPreviousReturnedCol = valeur de col à la ligne 14

---

Je ne sais pas si je suis clair? ^^ en fait prendre prendre les 15 prochaines lignes à partir de la dernière valeur renvoyée par la dernière requête.

Ceci fonctionne évidemment si, par défaut, les colonnes sont 'processées' dans l'ordre par Oracle.

Rhem... pas très clair ^^ ==> petit exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10

TableA ------- col1 aaa1 ddd2 bbb3 ccc4 eee5

---

si je fais:

Code:

---

1 2	select * from TableA where col1 > 'aaa1' and rownum < 3 order by col1

---

va-t-il me renvoyer, dans l'ordre:
bbb3
ddd2

ou est-ce que ça pourrait aussi être:
ccc4
eee5


En gros, est-ce que Oracle va me renvoyer les premières valeurs 'juste plus grandes' ou n'importe lesquelles?

Peut-être que ça dépend s'il y a un index ou pas aussi?

Bon, j'espère que je n'embrouille pas trop tout ^^

Merci

Damned, en réfléchissant j'ai déjà une petite idée de la réponse :(

(mais si quelqu'un pouvait confirmer ^^)

Pagination

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

select {list of columns} from ( select {list of columns}, rownum rn from ( {your select statement with order by} ) where rownum <= N * {your pagesize} ) v1 where v1.rn > (N-1) * {your pagesize} order by rn ;

---

oui, c'est la méthode par 'inline views'...

Mais je trouve ça couteux... vu qu'il doit quand même construire la view complète. C'est pour ça que je cherchais une 'astuce' plus efficace.

Merci quand même.

Citation:

---

Envoyé par bidi

...

Mais je trouve ça couteux... vu qu'il doit quand même construire la view complète. C'est pour ça que je cherchais une 'astuce' plus efficace.

Merci quand même.

---

:roll: ??? :roll:

Peut-être ne suis-je pas dans le bon mais ce que je pense:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

SELECT col1 FROM ( SELECT col1, rownum rn FROM ( select col1 from TableA where col1 < 5000 order by col1 ) WHERE rownum <= 4 * 15 ) v1 WHERE v1.rn > (4-1) * 15 ORDER BY rn ;

---

Le select en rouge va créer une inline view. si, cette inline view fait, mettons 10000 enregistrements, je n'en ai besoin que de 15 à la fois. Même si ça n'arrive pas chez le client, j'imagine qu'une inline view de 10000 enregistrement ça doit être difficile à digérer par Oracle non?

Enfin, en écrivant,je me redis que c'est un peu bête... les requirements sont pourris ^^. Je ne vois pas trop l'intérêt de paginer un si grand nombre de résultats... mais bon, les utilisateurs... ^^

Merci pour ton aide

Il y a eu une longue discution sur les performances ici AskTom

Ha oui, j'avais déjà lu cette looongue discussion ^^.

Je pense que c'est juste la requête de base qui est trop lourde.

Je pense que je vais limiter celle-ci et ça devrait être bon.

Afin de limiter, je procède comme suit:

Code:

---

1 2	select count(*) from TableA where col1<5000 and rownum<=500

---

Si j'ai 500, je dis alors à l'utilisateur que ses critères ne sont pas assez précis.

Y'a-t-il un autre moyen plus efficace de réaliser ce 'count'?

J'avais lu, dans les articles de Tom, d'utiliser v$sql_plan pour avoir une estimation du nombre de résultats mais ça me semble bien 'aléatoire'.

Si la requête de base est lourde il faut travailler sur cette requête. Compter les enregistrements en plus de l’exécution de la requête c’est toujours plus cher qu’exécuter uniquement la requête. La remarque du Tom est qu’on pourrait travailler souvent avec une estimation et non pas avec le nombre exact des enregistrements, d’où l’idée d’utiliser les cardinalités estimés par l’optimiseur.
Mais… pagination rime avec moteur de recherche. Moteur de recherche rime avec avoir vite une réponse. Et tout cela veut dire qu’il faut que la requête s’exécute dans la plus part de cas dans quelques secondes. Donc cella abouti à la même conclusion : optimiser la requête de base.

Sur ta dernière question la réponse est : en principe oui c’est possible. Le moyen le plus efficace de réaliser un count est de ne pas le réaliser :lol:. Donc si fonctionnellement tu pourrais pré calculer les count c’est plus efficace. Mais je peur que cette technique n’est pas toute à fait adaptée à un moteur de recherche.

Salut !

Tom Kyte est un héros.
J'ai autant aimé la croisade contre le sms que la "devise" :
Claims -- don't want em.
Benchmark, metrics, statistics -- love em -- want em -- need em.


Bon cela dit, pour ne pas suivre la recommandation (un peu par flemme :aie:), je vous demande :
Est-ce que ntile va aussi vite ?

Code:

---

1 2 3 4 5 6 7

SELECT * FROM (SELECT ntile(granularite) OVER (ORDER BY NULL) AS page, lereste FROM Tatable WHERE Tonfiltre) WHERE page Between tesbornes

---

Citation:

---

Envoyé par pacmann

...
Est-ce que ntile va aussi vite ?
...

---

Salut pacmann,

Je ne pense pas que cette requête peut battre la classique.