Celui-ci présentait également deux entrées où ‘shiny-server’ correspondait à une seule, mais ‘%hiney-server’ correspondait aux deux. Je ne vois pas en quoi cela m’aide à comprendre, mais je pense que vous voulez dire que le select que j’exécute s’attend à ce qu’un seul élément soit renvoyé et le récupère depuis l’index, en ignorant l’autre, tandis que lorsque j’utilise le %, il recherche dans les champs.
discourse=> EXPLAIN ANALYZE select * from tags where name='shiny-server';
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------
Index Scan using index_tags_on_name on tags (cost=0.28..8.29 rows=1 width=36) (actual time=0.038..0.040 rows=1 loops=1)
Index Cond: ((name)::text = 'shiny-server'::text)
Planning time: 0.129 ms
Execution time: 0.070 ms
(4 rows)
Je doute fort que quiconque ne parvenant pas à comprendre cela de lui-même trouve cela utile, mais… J’ai effectué plusieurs recherches pour trouver les deux tag_id ayant le même nom et j’ai exécuté des opérations comme :
TopicTag.where(tag_id: 717).update_all(tag_id: 611)
Tag.ensure_consistency!
Tag.find(717) # s'assurer qu'il n'est associé à aucun sujet
Tag.find(717).destroy
puis j’ai exécuté reindex table tags; dans psql.
Il semble maintenant que je doive faire de même pour users, un peu comme l’a décrit @bartv. Cependant, avec mes utilisateurs, je vois un utilisateur nommé David et un autre nommé david, ainsi que [Mm]ark.
Pour ceux-ci, j’ai procédé ainsi :
marks=User.where("username similar to '[Mm]+ark'").pluck(:id,:username,:created_at)
Ensuite, j’ai repéré le nouveau Mark dans /admin/users et renommé l’utilisateur depuis l’interface. Puis j’ai tenté d’exécuter reindex table users; dans psql (sudo su - discourse puis psql).