Re: SQL pour trouver le premier libre?

Re,

> le probleme, c'est que ca aussi, ca doit faire un full table scan sur la table
> nombres... ca en fait meme 2 :)
> c'est une requete qui est potentiellement longue si il y a beaucoup
d'enreg.

Pas sûr. Dans mon exemple, la table de test est tellement ridicule que
je n'ai pas mis d'index, et pour cause, il ne serait évidement pas utilisé.

Par contre, dans le contexte d'une table beaucoup plus grosse, disons
quelques millions d'enregistrements (?), ça peut valoir le coup.

Mais c'est la requête sur le a+1 qui va probablement faire un full scan,
oui.

Alors je me dis que créer un index fonctionnel sur (a+1) est peut être
une bonne solution...

Mais au final, ça fait un index de plus à "entretenir", et les
inserts/updates en seront lésés!

En tout cas, tout cela mérite un test. Je fais confiance à Pierre pour
qu'il revienne vers nous et nous dise si c'est mieux ou moins bien..

> je ne pense pas qu'il y ait une solution économique en perfs pour ce genre de
> traitements, du moins pas directement en SQL.

Ça se teste, donc. Bien souvent, transformer ce genre de traitements
avec des requêtes qui jouent avec des ensembles (union, except, etc..)
améliore considérablement les perfs.

> a mon avis, il serait plus performant, à chaque modification de la table de
> liste de nombres, de déclencher un trigger qui entretiendrait une table de
> liste d'elements libres...

Oui c'est ce qui se fait dans ce genre de cas.

> le mieux étant de ne pas faire du tout ce remplissage, si possible. y a t'il
> un réel besoin fonctionnel à ce remplissage ? ne peut on pas prendre le max
> de la liste +1 (dans ce cas, utilisation d'une séquence...)

Ça aussi c'est une bonne question...

A+

--
Jean-Paul Argudo
www.PostgreSQLFr.org