Vous n'êtes pas identifié(e).
Pas de quoi ;-)
Puisqu'on est dans les "petits bugs", votre message est horodaté à aujourd'hui 15:02:41 alors qu'il n'est que 14h20 (retour vers le futur...)
Merci pour tout le travail réalisé
Bonjour,
Tout d'abord un grand merci et un grand bravo aux animateurs de l'indispensable site Postgresql.fr.
Je me permets de signaler une erreur dans la zone documentation; lorsque l'on lance une recherche, les résultats pointent vers des pages en http://docs.postgresqlfr.org, domaine qui n'existe plus, Tous les résultats génèrent donc des erreurs 404, et il faut modifier l'URL à la main pour afficher les résultats.
Encore merci à tous
Bonjour,
Si vous lisez l'anglais, il y a un article sur ce sujet, que je trouve très pédagogique, dans le numéro d'août de BSD Magazine, qui peut être téléchargé ici:
http://bsdmag.org/magazine/1809-tuning-zfs-on-freebsd
Ok, super !
Il y a bien le sous-répertoire évoqué ici; c'est une très bonne nouvelle :-)
C'est dommage que le manuel de pg_upgrade ne le dise pas.
En tous cas, merci beaucoup pour cette information oh combien rassurante.
PS: et j'avais bien exclus, malgré les gains de temps énormes, l'option des liens. Trop dangereux !
Merci pour la réponse.
Je sais que c'est le répertoire principal qu'il faut donner. Mais ma question concerne la migration des données n'étant pas dans ce répertoire principal.
Pour prendre un exemple concret, mon répertoire principal actuel est "/disk2/pgsql/9.0/data", mais j'utilise 2 autres tablespace qui ont pour emplacements /disk3/pgsql/9.0/data et /disk4/pgsql/9.0/data
La logique , telle que j'ai comprise, est d'appeler pg_upgrade avec les paramètres --old-datadir=/disk2/pgsql/9.0/data et --new-datadir=/disk2/pgsql/9.2/data. Et j'aurais bien les données migrée du répertoire principal dans /disk2/pgsql/9.2/data. Mais que ce passera-t-il pour les 2 autres répertoires ? Va-t-il migrer les données de /disk3/pgsql/9.0/data, m'empêchant ainsi tout downgrade ultérieur ? Va-t-il échouer en considérant que le répertoire n'est pas vide et contient des données d'une version incompatible ?
Dans l'esprit, il semblerait logique de vouloir dire que les données de /disk3/pgsql/9.0/data seront migrées dans /disk3/pgsql/9.2/data et celles de /disk4/pgsql/9.0/data dans /disk4/pgsql/9.2/data. Mais, si j'ai compris la doc, pg_upgrade ne permet pas cela. C'est même encore plus simple, la problématique des tablespaces n'est pas évoquée dans le manuel de pg_upgrade, d'où ma question.
Bonjour,
J'ai une base en production sous PosgreSQL 9.0 que j'envisage migrer prochainement. Pour cela, je pensais utiliser pg_upgrade. Mais, parmi ses paramètres, il attend le chemin des anciennes données et des nouvelles. Ce paramétrage simple fonctionne correctement lorsque toutes les données sont regroupées au même endroit; mais ma base est répartie via des tablespaces sur plusieurs disques.
Quelle est dans ce cas la méthode à suivre ?
Aïe ! Pas cool ça !
A vrai dire, avant de migrer mon serveur en version 9, ma BDD était "encodée" (si on peut dire !) en SQL_ASCII, ce qui me posait d'autres soucis dans la mesure ou les tris étaient sensibles aux accents. Par contre, tous les caractères étaient bien pris en compte.
Bon, tant pis, je vais contourner le problème au niveau applicatif.
En tous cas, merci pour votre réponse.
Bonjour,
J'ai une requête SELECT du type
SELECT ma_valeur FROM ma_table ODRER BY ma_valeur
dans une table encodée en UTF8 avec comme "collation" et comme "type de caractère" fr_FR.UTF8
Parmi les résultats de cette requête, j'obtiens notamment (dans cet ordre):
...
Ajaccio
[Ajaccio]
Alagnon
...
Cet ordre est logique par rapport au comportement prévu. Néanmoins, dans mon cas particulier, j'aurais souhaité que les caractères autres que des lettres (les crochets dans l'exemple ci-dessus) soient pris en compte pour mon tri; en d'autres termes, j'aurais souhaité:
[Ajaccio]
...
Ajaccio
Alagnon
...
Est-ce possible ?
Et bien entendu, comment ?
Par avance, merci pour votre aide
Comme je le dis dans mon précédent post, ils sont tous à leur valeur par défaut; plus précisément, tous les paramètres concernant l'autovacuum sont "commentarisés" sauf autovacuum=on
Par ailleurs, parmi les processus actifs (au sens système), j'ai un processus "postgres: autovacuum launcher process" qui tourne.
Bonjour,
Je viens d'exécuter la requête d'analyse des statistiques ci-dessus sur ma propre BDD et je constate que les colonnes lastautovacuum et lastautoanalyze sont vides pour presque toutes les tables! Le paramètre autovaccuum est pourtant à "on" (toutes les options concernant ce paramètre ont les valeurs par défaut). Dois-je m'en inquiéter ?
Le résultat d'Explain analyse est le suivant:
"Aggregate (cost=3735.82..3735.83 rows=1 width=0) (actual time=3460.170..3460.171 rows=1 loops=1)"
" -> Seq Scan on presse_pdf_contenu (cost=0.00..3665.51 rows=28122 width=0) (actual time=0.377..3446.645 rows=27890 loops=1)"
" Filter: (pres_pdf_contenu_vecteur @@ '''seanc'''::tsquery)"
"Total runtime: 3460.248 ms"
La base est sous PostgreSQL 9.0.1 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48), 64-bit
Et votre analyse était la bonne; en effet, si je change la 1ère requête pour une recherche plus restrictive, alors l'index est bien utilisé:
Exemple:
SELECT *
FROM
presse_pdf_contenu
WHERE
pres_pdf_contenu_vecteur @@ to_tsquery('fr','france & allemagne & algerie')
"Bitmap Heap Scan on presse_pdf_contenu (cost=29.10..37.03 rows=2 width=49) (actual time=19.460..20.743 rows=778 loops=1)"
" Recheck Cond: (pres_pdf_contenu_vecteur @@ '''franc'' & ''allemagn'' & ''alger'''::tsquery)"
" -> Bitmap Index Scan on idx_presse_vecteur (cost=0.00..29.10 rows=2 width=0) (actual time=19.381..19.381 rows=778 loops=1)"
" Index Cond: (pres_pdf_contenu_vecteur @@ '''franc'' & ''allemagn'' & ''alger'''::tsquery)"
"Total runtime: 20.966 ms"
SELECT *
FROM
presse_pdf_contenu
WHERE
pres_pdf_contenu_vecteur @@ to_tsquery('fr','france & allemagne')
"Seq Scan on presse_pdf_contenu (cost=0.00..3665.51 rows=412 width=49) (actual time=0.051..2404.342 rows=6639 loops=1)"
" Filter: (pres_pdf_contenu_vecteur @@ '''franc'' & ''allemagn'''::tsquery)"
"Total runtime: 2406.538 ms"
Merci pour cette information. J'ai encore beaucoup de choses à apprendre ... ;-)
Effectivement, la requête retourne environ 28000 lignes.
Et si j'execute par exemple
SELECT count(*)
FROM
presse_pdf_contenu
WHERE
pres_pdf_contenu_vecteur @@ to_tsquery('fr','seance')
le résultat est BEAUCOUP plus rapide (32ms)
J'en déduis donc, que ce n'est pas la requête elle-même qui prend du temps, mais la lecture sur disque des résultats, exact ?
Merci pour cette réponse extrêmement rapide.
La table compte environ 90 000 lignes. Elle "pèse" 7Mo, et l'index 1.8Go. A côté, j'ai aussi l'indication "Taille de la table TOAST: 21Go", mais je ne sais pas ce que c'est ;-)
Enfin, le explain analyse retourne:
"Seq Scan on presse_pdf_contenu (cost=0.00..3665.51 rows=28122 width=49) (actual time=0.111..2344.661 rows=27890 loops=1)"
" Filter: (pres_pdf_contenu_vecteur @@ '''seanc'''::tsquery)"
"Total runtime: 2352.961 ms"
Encore merci pour la réponse
Bonjour,
Je dispose d'une table (contenant environ 90 000 lignes) créée comme suit:
CREATE TABLE presse_pdf_contenu
(
id_presse_pdf_contenu serial NOT NULL,
pres_pdf_page integer,
pres_pdf_contenu text,
pres_pdf_contenu_vecteur tsvector,
id_presse_pdf integer
)
La colonne pres_pdf_contenu_vecteur est indexée (gin)
CREATE INDEX idx_presse_vecteur
ON presse_pdf_contenu
USING gin
(pres_pdf_contenu_vecteur);
Mais, si j'exécute une requête telle que:
SELECT *
FROM
presse_pdf_contenu
WHERE
pres_pdf_contenu_vecteur @@ to_tsquery('fr','seance')
l'index n'est pas utilisé, d'où des temps catastrophiques (environ 5 minutes pour la présente requête)
Sortie de l'explain:
"Seq Scan on public.presse_pdf_contenu (cost=0.00..3665.51 rows=28122 width=49)"
" Output: id_presse_pdf_contenu, pres_pdf_page, pres_pdf_contenu, pres_pdf_contenu_vecteur, id_presse_pdf"
" Filter: (presse_pdf_contenu.pres_pdf_contenu_vecteur @@ '''seanc'''::tsquery)"
Avez-vous une idée pouvant m'aider à sortir de ce mauvais pas ?
Cordialement
Bonjour,
Interpellé par ce thread, j'ai jeté un coup d'oeil à mon propre fichier de configuration (sous CentOS).
J'y lis des valeurs telles que:
- shared_buffers = 7680MB
- maintenance_work_mem = 1GB
etc...
A priori, ces paramètres avec unités semblent licites et, sous réserve que ce soit bien la cas, moins sujet à erreurs d'interprétations que des simples valeurs numériques
En fait, j'interviens sur un projet dont l'interface utilisateur est développée sous ExtJS (un framework Javascript offrant des widgets type "client lourd").
Dans ce projet, il est possible de modifier des tables d'une base PostgreSQL via une "pseudo-fenêtre modale" (je parle de "pseudo", car il ne s'agit d'une vraie fenêtre type popup de navigateur). Ce que j'aurais voulu, c'est que, si l'utilisateur ferme cette pseudo-fenêtre sans avoir cliqué sur le bouton Enregistrer, autrement dit, en cliquant soit sur la case de fermeture, soit sur le bouton Annuler, on retrouve l'état initial.
Beaucoup de widgets d'ExtJS fonctionnent via des appels asynchrones faciles à implémenter en liaison avec une base (par exemple, des treeviews, des grilles,...)
Alors, bien sûr, il est possible de réaliser ce que je souhaite, par exemple en dupliquant la structure à éditer dans un jeu de tables temporaires qui viendront écraser les anciennes données en cas d'enregistrement, mais c'est particulièrement lourd, étant donné le nombre de tables en jeu. Et ça reste "usine à gaz" alors que le mécanisme des transactions, que j'utilise fréquemment dans des scripts "classiques" fonctionne à merveille et réponds totalement à mes besoins.
Ce que je n'avais pas prévu, c'est que, bien qu'étant dans une opération unitaire et modale en terme d'interface utilisateur, ça reste de l'asynchrone en terme d'architecture. Ce qui n'aurait posé aucun problème dans un environnement "client lourd" classique, devient donc problématique dans ce "bureau web"
Je suis désolé de ne pas pouvoir envoyer de lien pour illustrer mes propos, mais il s'agit d'un intranet privé.
Et j'espère surtout avoir été à peu près clair.
Encore merci à tous ceux qui ont pris la peine de me répondre.
Le problème est qu'il faut que vous soyez conscient que la montée en charge en sera fortement altérée avec des problématique de survenance de verrous mortels....
A +
Il s'agit d'un back-office, dont l'accès de ne concerne que quelques personnes (j'ai plus de serveurs que d'utilisateurs dans ce cas ;-) ). La montée en charge est donc un problème qui ne se pose pas.
Par ailleurs, je me permets 2 petites remarques:
1- on ne choisit pas toujours ni son environnement de travail, ni son langage, ni son framework, surtout en entreprise.
2- un projet qui vit peut évoluer vers des directions non prévues initialement. Du coup, un choix judicieux à un instant donné peut, dans certaines circonstances, s'avérer partiellement ou totalement malheureux. Ce n'est pas pour autant (par exemple pour rajouter ue fonctionnalité), que l'on remet systématiquement par terre des années de développement. Tout ça pour dire que ces jugements péremptoires, s'ils peuvent être exacts en théorie, n'ont aucun sens face à des situations rélles qui sont toutes par définition des cas particuliers. Mais bon, je le sais, la mode est aux donneurs de leçons...
Bonjour,
J'ai de la chance, SQLPro connait mieux mon projet que moi, et la pertinence de ses réponses m'a aidé à résoudre mon problème :-))
(et ça tombe bien, je souhaite effectivement que les tables soient verrouillées; c'est exactement ce que je cherche à faire)
Et je suis quasiment sûr qu'il était possible de le faire via un "SET AUTOCOMMIT TO OFF" jusqu'aux version 7.3.x
(voir par exemple http://archives.postgresql.org/pgsql-ge … 00064.php)
C'était bien évidemment mon premier réflexe.
Malheureusement, ce n'est pas si simple que cela. En effet, mon interface est "Full Ajax" (basée sur la librairie extJS) et les différentes requêtes sont donc appelées via des scripts distincts, appelés de façon asynchrone. Or, visiblement, à la fin de chaque script, un COMMIT (en l'occurrence un AUTO-COMMIT donc) est réalisé.
Si j'appelle à la fermeture de ma pseudo-fenêtre (via un nouvel appel AJAX) un "simple" Rollback, rien ne se passe, puisque tout a déjà été commité (normal !)
D'où ma question: est-il possible de désactiver provisoirement l'autocommit ?
Etant donné le fruit de mes recherches, et les premières réponses fournies ici, je crains le pire...
Pourtant, cette fonctionnalité a existé par le passé, et je m'étonne de tomber sur une régression, aussi motivée soit-elle. PostgreSQL ne nous avait pas habitué à cela...
Bonjour,
Pour un besoin particulier, j'aurais souhaité désactiver temporairement l'autocommit (à partir d'un projet en PHP).
Malheureusement, il n'est plus possible (depuis la version 7.4 je crois) d'envoyer un SET AUTOCOMMIT OFF.
Dans la documentation, je ne trouve que la possibilité de le désactiver globalement (via postgresql.conf) ou dans pgsql (de mémoire via \set autocommit off)
Existe-t-il une possibilité via SQL ?
Par avance, merci
Super, merci !
Le mot-clé qui me manquait pour que ma recherche aboutisse est donc...trigramme
Ca ne s'invente pas !
Je vais voir ça de plus prêt, les perspectives étant particulièrement intéressantes.
Bonjour,
Je sais qu'il existe une solution pour, à partir d'une recherche plein texte donnée, proposer des termes "proches" (notamment en cas de fautes de frappe ou d'orthographe), comme le propose notamment le moteur de recherche dans la documentation de PostgreSQL, mais impossible de retrouver la solution en question.
Pourriez-vous SVP m'aiguiller sur la bonne piste.
Par avance, merci à tous
PS: Et par la même occasion, tous mes meilleurs voeux pour cette nouvelle année
Effectivement, la colonne peut être grosse; elle contient le contenu de fichiers bureautiques qui peuvent aller jusqu'à plusieurs centaines de pages !
Et je confirme ce que vous dites: la fonction n'est bien appliquée QUE sur les enregistrements retournés.
Du coup, je m'en suis tiré avec une "pirouette" consistant:
1- A appeler la rechercher sans le ts_headline, afin de pouvoir afficher les résultats immédiatement
2- Appel de la fonction ts_headline en asynchrone (via Ajax) pour remplir dans un 2ème temps les extraits des documents.
Le code est plus lourd, génère plus de requetes HTTP et est moins satisfaisant pour l'utilisateur, mais c'est un compromis permettant un affichage des résultats rapide.
Merci pour votre aide.
Ne reste plus qu'à espérer qu'une prochaine version améliorera les performances de cette fonction (qui, dans l'état actuel, sont, il faut bien le reconnaitre- assez médiocres)
Merci pour votre réponse.
La version de Postgres utilisée est:
PostgreSQL 9.0.1 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48), 64-bit
La sortie de Explain Analyse est:
"Limit (cost=5381.05..5382.07 rows=410 width=655) (actual time=10208.591..10208.624 rows=38 loops=1)"
" -> Sort (cost=5381.05..5382.07 rows=410 width=655) (actual time=10208.587..10208.600 rows=38 loops=1)"
" Sort Key: ir_instrument_recherche.id_ir_instrument_recherche"
" Sort Method: quicksort Memory: 45kB"
" -> Nested Loop (cost=3774.81..5363.25 rows=410 width=655) (actual time=681.273..10208.392 rows=38 loops=1)"
" -> Function Scan on r (cost=0.00..0.01 rows=1 width=32) (actual time=0.011..0.013 rows=1 loops=1)"
" -> Bitmap Heap Scan on ir_instrument_recherche (cost=3774.81..5356.07 rows=410 width=623) (actual time=16.675..17.273 rows=38 loops=1)"
" Recheck Cond: ((ir_instrument_recherche.ir_inst_rech_vecteur @@ r.r) AND (ir_instrument_recherche.id_ir_instrument = ANY ('{3934,3434,3438,4266,4264,4265,4414,4413,4412,3006,3005,607,3005,607,4488,242,243,244,245,246,247,248,249,250,253,251,252,610,581,607,586,589,590,591,579,580,608,585,588,606,582,587,605,1276,1275,1500,1499,910,3427,3424,3470,3483,3484,3481}'::integer[])))"
" -> BitmapAnd (cost=3774.81..3774.81 rows=410 width=0) (actual time=16.643..16.643 rows=0 loops=1)"
" -> Bitmap Index Scan on idx_vecteur_rech (cost=0.00..1785.14 rows=1782 width=0) (actual time=0.391..0.391 rows=485 loops=1)"
" Index Cond: (ir_instrument_recherche.ir_inst_rech_vecteur @@ r.r)"
" -> Bitmap Index Scan on idx_id_ir_instrument_rech (cost=0.00..1968.82 rows=81999 width=0) (actual time=16.093..16.093 rows=92620 loops=1)"
" Index Cond: (ir_instrument_recherche.id_ir_instrument = ANY ('{3934,3434,3438,4266,4264,4265,4414,4413,4412,3006,3005,607,3005,607,4488,242,243,244,245,246,247,248,249,250,253,251,252,610,581,607,586,589,590,591,579,580,608,585,588,606,582,587,605,1276,1275,1500,1499,910,3427,3424,3470,3483,3484,3481}'::integer[]))"
"Total runtime: 10208.763 ms"
Je ne comprends pas a priori en quoi l'ajout du ts_headline impacterait le tri, puisqu'il est le même dans les 2 requêtes données en exemple (ORDER BY id_ir_instrument_recherche)
Je me demande plutôt si la fonction ts_headline n'est pas appliquée sur toutes les lignes, et non sur "seulement" les 38 lignes de résultats ?
Bonjour,
Je développe actuellement un nouveau moteur de recherche pour notre site, basé sur les fonctions de recherche plein texte de PostgreSQL (v9.0.1 sur bi quad-Xeon 32Go RAM -RedHat 5 x86_64 bits), mais je rencontre un problème de performance, liée à l'utilisation de ts_headline.
Exemple typique d'une requête que j'effectue:
SELECT
ir_instrument_recherche.id_ir_instrument_recherche,
ts_headline('fr', ir_inst_rech_col1,r, 'MaxFragments=4') AS extrait,
ts_rank_cd(ir_inst_rech_vecteur,r) AS score
FROM
ir_instrument_recherche, to_tsquery('fr','jerome') AS r
WHERE
id_ir_instrument IN (3934,3434,3438,4266,4264,4265,4414,4413,4412,3006,3005,607,3005,607,4488,242,243,244,245,246,247,248,249,250,253,251,252,610,581,607,586,589,590,591,579,580,608,585,588,606,582,587,605,1276,1275,1500,1499,910,3427,3424,3470,3483,3484,3481) AND ir_inst_rech_vecteur @@ r ORDER BY id_ir_instrument_recherche LIMIT 5000
=> S'exécute en plus de 10 secondes pour 38 résultats !!!
Explain:
"Limit (cost=5381.05..5382.07 rows=410 width=655)"
" -> Sort (cost=5381.05..5382.07 rows=410 width=655)"
" Sort Key: ir_instrument_recherche.id_ir_instrument_recherche"
" -> Nested Loop (cost=3774.81..5363.25 rows=410 width=655)"
" -> Function Scan on r (cost=0.00..0.01 rows=1 width=32)"
" -> Bitmap Heap Scan on ir_instrument_recherche (cost=3774.81..5356.07 rows=410 width=623)"
" Recheck Cond: ((ir_instrument_recherche.ir_inst_rech_vecteur @@ r.r) AND (ir_instrument_recherche.id_ir_instrument = ANY ('{3934,3434,3438,4266,4264,4265,4414,4413,4412,3006,3005,607,3005,607,4488,242,243,244,245,246,247,248,249,250,253,251,252,610,581,607,586,589,590,591,579,580,608,585,588,606,582,587,605,1276,1275,1500,1499,910,3427,3424,3470,3483,3484,3481}'::integer[])))"
" -> BitmapAnd (cost=3774.81..3774.81 rows=410 width=0)"
" -> Bitmap Index Scan on idx_vecteur_rech (cost=0.00..1785.14 rows=1782 width=0)"
" Index Cond: (ir_instrument_recherche.ir_inst_rech_vecteur @@ r.r)"
" -> Bitmap Index Scan on idx_id_ir_instrument_rech (cost=0.00..1968.82 rows=81999 width=0)"
" Index Cond: (ir_instrument_recherche.id_ir_instrument = ANY ('{3934,3434,3438,4266,4264,4265,4414,4413,4412,3006,3005,607,3005,607,4488,242,243,244,245,246,247,248,249,250,253,251,252,610,581,607,586,589,590,591,579,580,608,585,588,606,582,587,605,1276,1275,1500,1499,910,3427,3424,3470,3483,3484,3481}'::integer[]))"
----------------------------------------------------------------------------------------
Variante *SANS* ts_headline:
SELECT
ir_instrument_recherche.id_ir_instrument_recherche,
ts_rank_cd(ir_inst_rech_vecteur,r) AS score
FROM
ir_instrument_recherche, to_tsquery('fr','jerome') AS r
WHERE
id_ir_instrument IN (3934,3434,3438,4266,4264,4265,4414,4413,4412,3006,3005,607,3005,607,4488,242,243,244,245,246,247,248,249,250,253,251,252,610,581,607,586,589,590,591,579,580,608,585,588,606,582,587,605,1276,1275,1500,1499,910,3427,3424,3470,3483,3484,3481) AND ir_inst_rech_vecteur @@ r ORDER BY id_ir_instrument_recherche LIMIT 5000
=> S'exécute en 33 ms (ouf !!!)
Explain:
"Limit (cost=5380.02..5381.05 rows=410 width=514)"
" -> Sort (cost=5380.02..5381.05 rows=410 width=514)"
" Sort Key: ir_instrument_recherche.id_ir_instrument_recherche"
" -> Nested Loop (cost=3774.81..5362.23 rows=410 width=514)"
" -> Function Scan on r (cost=0.00..0.01 rows=1 width=32)"
" -> Bitmap Heap Scan on ir_instrument_recherche (cost=3774.81..5356.07 rows=410 width=482)"
" Recheck Cond: ((ir_instrument_recherche.ir_inst_rech_vecteur @@ r.r) AND (ir_instrument_recherche.id_ir_instrument = ANY ('{3934,3434,3438,4266,4264,4265,4414,4413,4412,3006,3005,607,3005,607,4488,242,243,244,245,246,247,248,249,250,253,251,252,610,581,607,586,589,590,591,579,580,608,585,588,606,582,587,605,1276,1275,1500,1499,910,3427,3424,3470,3483,3484,3481}'::integer[])))"
" -> BitmapAnd (cost=3774.81..3774.81 rows=410 width=0)"
" -> Bitmap Index Scan on idx_vecteur_rech (cost=0.00..1785.14 rows=1782 width=0)"
" Index Cond: (ir_instrument_recherche.ir_inst_rech_vecteur @@ r.r)"
" -> Bitmap Index Scan on idx_id_ir_instrument_rech (cost=0.00..1968.82 rows=81999 width=0)"
" Index Cond: (ir_instrument_recherche.id_ir_instrument = ANY ('{3934,3434,3438,4266,4264,4265,4414,4413,4412,3006,3005,607,3005,607,4488,242,243,244,245,246,247,248,249,250,253,251,252,610,581,607,586,589,590,591,579,580,608,585,588,606,582,587,605,1276,1275,1500,1499,910,3427,3424,3470,3483,3484,3481}'::integer[]))"
Malheureusement, j'ai pourtant besoin de cet extrait...
Avez-vous une piste à me suggérer car là, je sèche...
Par avance, merci
