Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
Je cherche à remplacer certains indexs de ma base trop bloatés par des indexs recréés via un "create index concurrently" , suivi d'un "drop index idx ; alter index idx_new rename to idx" englobé dans une transaction.
Je me pose une question sur comment la base fonctionne pendant le laps de temps ou les 2 indexs coexistent, le temps que le drop / rename ait eu lieu.
Comment la base sait quel index elle doit interroger ?
Est ce que cela peut poser des problèmes ?
Merci
Hors ligne
S'il s'agit exactement du même index (même déclaration), PostgreSQL utilisera le plus petit (donc à priori le nouveau, si vous craignez le bloat). Si vous faites tous dans une transaction, cela peut poser quelques soucis à cause des verrous posés. Cela étant dit, je ne vois pas l'intérêt d'englober ces ordres dans une transaction. En fait, je vois des inconvénients mais aucun avantage... pour le dire autrement, je ne le ferais pas 
Guillaume.
Hors ligne
Oui, il s'agit du même index, le but étant de ne pas voir mes indexs grandir indéfiniment en terme d'espace disque notamment.
Je n'avais pas réussi à trouver cette information dans la doc...
Je ne fais pas tout dans une transaction, juste le drop de l'ancien index et le rename du nouveau (toto_idx_new) pour lui donner le nom de l'ancien (toto_idx), dans le but d'éviter le cas de figure ou le drop se passe bien, et le rename non. (et donc dans ce cas, et si je vous suit bien, mon index sera tout de même fonctionnel, il n'aurait juste pas le bon nom ?)
Hors ligne
Oui, il aura juste l'ancien nom.
Guillaume.
Hors ligne
Bonjour
Quelles sont les avantages de cette méthode par rapport à REINDEX
Merci d'avance.
Hors ligne
Bonjour,
le CREATE INDEX CONCURRENTLY suivi d'un DROP INDEX permet de ne pas bloquer la table durant la reconstruction.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour
Merci de la réponse
Hors ligne
bonjour,
j'ai mis en place cette solution depuis quelques jours et elle fonctionne bien, et ce jour, j'ai eu un soucis lors du drop d'un index (non utilisé du coup, comme un nouvel index avait été créé) : la requete a mis beaucoup de temps a s’exécuter, et a mis en Wait toutes les requêtes suivantes.
Pourriez vous m'expliquer pourquoi cela se produit ?
Merci d'avance !
Hors ligne
Bonjour,
la commande CREATE INDEX CONCURRENTLY peut parfois échouer, auquel cas le nouvel index sera marqué comme non valide et la suppression de l'ancien index sera bloquante. Peut-être est-ce la cause de votre soucis.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour rjuju, merci pour le retour.
Le problème vient en fait du temps que met postgres pour fixer un exclusive lock sur la table avant de pouvoir drop l'index.
Pour info si cela en intéresse certains, il a été rajouté une option concurrently sur le drop à partir de la 9.2
Hors ligne
Pages : 1
