Vous n'êtes pas identifié(e).
Pages : 1
Merci Gleu pour vos précisions.
Ma question est de savoir comment faire que ma requête ne devienne pas trop couteuse avec le temps et de voir comment gérer au mieux la problématique du multi valeurs.
Vaut il mieux faire un select avec 3000 "OR" : SELECT DEVICE WHERE sn like '0021%' or sn like '12B0%' or sn like '0000%' or sn like '26FF%' or sn like '65FA%' ...
ou alors, vaut il mieux faire un select avec une regexp qui liste les 3000 numéros de séries possibles : "SELECT DEVICE WHERE sn ~ '^0021|^12B0|^0000|^26FF|^65FA...' "
ou y a t il plus performant (jointure ?) ?
Vu que la colonne est indexée, il doit bien y avoir une manière optimisée de faire la recherche.
Merci par avance pour vos lumières.
Petit complément, j'ai aussi pensé à une piste sur les regexp, cela pourrait s'écrire :
SELECT DEVICE WHERE sn ~ '^0021|^12B0|^0000|^26FF|^65FA...'
Et j'ai peur que la chaine construite soit trop longue.
Bonjour,
je cherche à écrire une requête qui ne tape que sur une seule table et une seule colonne ...
Ma table DEVICE contient environ 50 000 lignes, présente une colonne "sn" de type character varying(255) et est indexée.
Je dois rechercher les lignes de cette table qui commencent par telle, ou telle, ou telle, ou telle, ... valeur. Cette liste de valeurs possibles peut être grande (2000, 3000 valeurs).
La requête ressemblerait à ceci :
SELECT DEVICE WHERE sn like '0021%' or sn like '12B0%' or sn like '0000%' or sn like '26FF%' or sn like '65FA%' ...
Les valeurs recherchées n'ont pas de logique particulière, cela correspond à des numéros de séries.
En pratique il y a environ 8-10 lignes qui sont retournées pour chaque clause (ex : il y a 10 lignes en base qui commencent par '0021')
Voyez vous une manière d'optimiser une telle requête ? (via une jointure, autre ?)
Merci par avance pour votre aide.
Christophe
Je suis parti sur la réinstall de la base à partir d'un dump, merci pour ton aide gleu.
Finalement, je ne peux pas faire la manip aujourd'hui ... Je te tiens informé quand je l'aurai fait. Merci
Merci Guillaume pour ta réponse si rapide ! Je tente ça dès demain. Pour te répondre, oui, oui, c'est bien dans pg_subtrans ... et c'est bien le fichier 0000. Merci pour le tuyau.
Voici le retour de "ps -ef | grep postgres" :
postgres 21880 1 0 07:54 ? 00:00:01 /usr/lib/postgresql/8.4/bin/postgres -D /srv/host-app/pgdata/main -c config_file=/etc/postgresql/8.4/main/postgresql.conf
postgres 21883 21880 0 07:54 ? 00:00:14 postgres: writer process
postgres 21884 21880 0 07:54 ? 00:00:03 postgres: wal writer process
postgres 21885 21880 0 07:54 ? 00:00:00 postgres: autovacuum launcher process
postgres 21886 21880 0 07:54 ? 00:00:02 postgres: stats collector process
admin 21930 1 1 07:54 ? 00:07:36 java -javaagent:/srv/host-app/myapp/myapptools/myapphome-21/play/framework/play.jar -Duser.timezone=GMT -Xmx512m -Xms512m -server ...
postgres 21952 21880 0 07:54 ? 00:01:40 postgres: myapp database2 127.0.0.1(46869) idle
postgres 21953 21880 0 07:54 ? 00:00:43 postgres: myapp database2 127.0.0.1(46870) idle
postgres 21954 21880 0 07:54 ? 00:01:26 postgres: myapp database2 127.0.0.1(46871) idle
postgres 21988 21880 0 07:58 ? 00:01:29 postgres: myapp database2 127.0.0.1(43760) idle
postgres 21989 21880 0 07:58 ? 00:00:05 postgres: myapp database2 127.0.0.1(43761) idle
postgres 21990 21880 0 07:58 ? 00:00:29 postgres: myapp database2 127.0.0.1(43762) idle
Je trouve qu'il y a beaucoup de monde ...
Dois je killer les processus notés "idle" ?
Merci
PS : J'ai aussi tenté de faire un VACUUM standard sur la base, ça a pris prêt de 5h (mais la base est conséquente), et je n'ai pas vu de pb dans le rapport. Merci
Bonjour,
je tourne sur un environnement linux avec un postgresql 8.4.
J'ai eu des soucis de place sur le disque dur, et j'ai ceci dans les logs :
DETAIL: Could not open file "pg_subtrans/0000": No such file or directory.
CONTEXT: automatic analyze of table "database2.pg_catalog.pg_opclass"
ERROR: could not access status of transaction 21374
Ce message apparait plein de fois dans les logs, et le pb semble venir de 5 transactions (21371 ... 21375).
Le fichier pg_subtrans/0000 était bien absent.
J'ai alors tenté de faire le fameux :
dd bs=8k count=1 < /dev/zero >> $PGDATA/pg_data/0000
voici le retour de la commande :
1+0 records in
1+0 records out
8192 bytes (8.2 kB) copied, 7.9429e-05 s, 103 MB/s
puis j'ai fait un chown postgres:postgres sur le fichier.
Maintenant, les logs sont les suivantes :
CONTEXT: automatic analyze of table "database2.pg_catalog.pg_index"
ERROR: could not access status of transaction 21373
DETAIL: Could not read from file "pg_subtrans/0000" at offset 81920: Success.
Il semble qu'il y ait toujours ces pb de transactions "suspendues" ...
Je sèche vraiment ...
Z'auriez des lumières à m'apporter plizzzz ??
Merci
Pages : 1
