Salut
Je fais un import toutes les nuits des données provenants d'un gros système.
j'ai remarqué que certaine requetes toutes simple prennent un temps
colossale.
Si je vire les index, tout va beaucoup plus vite lors de l'import, mais je
suis obligé de les recréer apres coup.
j'aimerai savoir s'il y a une ommande qui me permettrait de dire a postgres
de ne pas mettre a jour les indexes puis de les remettre a jour unefois
l'import terminé.
ils construit aucun fichiers d'index mais un dictionnaires de fichier ce qui remplace tout les index possibles sur le fichier (table) ce qui est différent
Un "dictionnaires de fichier" remplace tous les index en indexant tous les champs d'une table ? Bizarrement, dans la vraie vie, il y plein de champs sur lesquels on aura *jamais* besoin d'un index dessus.
En mettre partout ne fait donc que polluer l'espace disque (et le pacte écologique hein !), et chuter les performances en écriture, que le sgbd soit une F1 ou un cycle.
non car j'ai dit remplace pas créer les fichiers index
Ah, ça remplace sans création. C'est beau : on indexe tous les champs sans écrire l'index ! C'est l'effet couche propre ? L'indexation des champs où il n'y a pas lieu d'indexer est une perte d'espace et de temps, il va bien falloir l'admettre.
Aucune explication sur http://www.openqm.com02.net/ . Où est le lien vers la documentation ? A quel moment les informations du "dictionnaires de fichier" sont mises à jours ?
lit la doc qui est dans telechargements ou va sur la doc en ligne
-- Dr Thierry HOLZ HELIOS SERVICES 180 rue de la croix du chene 60250 HEILLES www.openqm.com02.net www.pick.com02.net
François Girault a écrit :
helios a écrit :
ils construit aucun fichiers d'index mais un dictionnaires de
fichier ce qui remplace tout les index possibles sur le fichier
(table) ce qui est différent
Un "dictionnaires de fichier" remplace tous les index en indexant
tous les champs d'une table ? Bizarrement, dans la vraie vie, il y
plein de champs sur lesquels on aura *jamais* besoin d'un index dessus.
En mettre partout ne fait donc que polluer l'espace disque (et le
pacte écologique hein !), et chuter les performances en écriture, que
le sgbd soit une F1 ou un cycle.
non car j'ai dit remplace pas créer les fichiers index
Ah, ça remplace sans création. C'est beau : on indexe tous les champs
sans écrire l'index ! C'est l'effet couche propre ? L'indexation des
champs où il n'y a pas lieu d'indexer est une perte d'espace et de
temps, il va bien falloir l'admettre.
Aucune explication sur http://www.openqm.com02.net/ . Où est le lien
vers la documentation ? A quel moment les informations du "dictionnaires
de fichier" sont mises à jours ?
lit la doc qui est dans telechargements ou va sur la doc en ligne
--
Dr Thierry HOLZ
HELIOS SERVICES
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
ils construit aucun fichiers d'index mais un dictionnaires de fichier ce qui remplace tout les index possibles sur le fichier (table) ce qui est différent
Un "dictionnaires de fichier" remplace tous les index en indexant tous les champs d'une table ? Bizarrement, dans la vraie vie, il y plein de champs sur lesquels on aura *jamais* besoin d'un index dessus.
En mettre partout ne fait donc que polluer l'espace disque (et le pacte écologique hein !), et chuter les performances en écriture, que le sgbd soit une F1 ou un cycle.
non car j'ai dit remplace pas créer les fichiers index
Ah, ça remplace sans création. C'est beau : on indexe tous les champs sans écrire l'index ! C'est l'effet couche propre ? L'indexation des champs où il n'y a pas lieu d'indexer est une perte d'espace et de temps, il va bien falloir l'admettre.
Aucune explication sur http://www.openqm.com02.net/ . Où est le lien vers la documentation ? A quel moment les informations du "dictionnaires de fichier" sont mises à jours ?
lit la doc qui est dans telechargements ou va sur la doc en ligne
-- Dr Thierry HOLZ HELIOS SERVICES 180 rue de la croix du chene 60250 HEILLES www.openqm.com02.net www.pick.com02.net
Thierry Boudet
On 2007-02-06, helios wrote:
Il est *certain* que la fonction nextval() retournera toujours une valeur différente.
mais nextval() ne fonctionnera pas si une transaction a virer l'index
Monsieur Docteur, pourriez-vous cesser de diffuser des contre-vérités, et que les générations futures ne soient pas perverties par vos pseudo-connaissances malsaines ?
-- Ce matin, j'ai laissé une console sans surveillance, en revenant j'ai vu ce message : "bash: win: command not found" !! -- Anonyme --
On 2007-02-06, helios <helios@com02.net> wrote:
Il est *certain* que la fonction nextval() retournera toujours une
valeur différente.
mais nextval() ne fonctionnera pas si une transaction a virer l'index
Monsieur Docteur, pourriez-vous cesser de diffuser des contre-vérités,
et que les générations futures ne soient pas perverties par vos
pseudo-connaissances malsaines ?
--
Ce matin, j'ai laissé une console sans surveillance, en revenant j'ai vu
ce message : "bash: win: command not found" !! -- Anonyme --
Il est *certain* que la fonction nextval() retournera toujours une valeur différente.
mais nextval() ne fonctionnera pas si une transaction a virer l'index
Monsieur Docteur, pourriez-vous cesser de diffuser des contre-vérités, et que les générations futures ne soient pas perverties par vos pseudo-connaissances malsaines ?
-- Ce matin, j'ai laissé une console sans surveillance, en revenant j'ai vu ce message : "bash: win: command not found" !! -- Anonyme --
