Vous n'êtes pas identifié(e).
Pages : 1
Merci pour l'information, cela m'intéresse de savoir que comportement est normal.
Pour la partie synonymes, j'ai déjà fait l'essai, mais cela n'est pas très satisfaisant,
car cela oblige à mettre toutes les villes dans le dictionnaire de synomymes
(Nantes n'était qu'un exemple) et ensuite j'ai peur effectivement des effets de bords !
Voici la manip ou cas ou cela intéresserait quelqu'un...je me suis basé sur la documentation en
français (merci au traducteur), chapitre 12.6.3 Dictionnaire des synonymes http://docs.postgresql.fr/8.3/textsearc … aries.html
1 export SHAREDIR=/post834/pgsql/share
2 cd $SHAREDIR/tsearch_data
3 vi my_mysynonym.syn
nantes nan
4 CREATE TEXT SEARCH DICTIONARY my_synonym(
TEMPLATE = synonym,
SYNONYMS = my_synonyms);
5 ALTER TEXT SEARCH CONFIGURATION french ALTER MAPPING
FOR asciiword WITH my_synonym, french_stem;
6 Essai avec ts_debug :
SELECT * FROM ts_debug('french', 'nantes');
alias | description | token | dictionaries | dictionary | lexemes
-----------+-----------------+-------+---------------+--------------+---------
asciiword | Word, all ASCII | nantes| {my_synonym,french_stem} | my_synonym | {nan}
7 essai avec to_tsquery :
SELECT * FROM ville where tsv @@ to_tsquery('nan');
localité | description | tsv
----------+--------------------------------------------+----------------------------
nantes | la ville de nantes est presque en bretagne | 'nan':1,5 'vill':3 'bretagn':9
Et encore merci pour votre aide !
Cela sera intéressant d'avoir un article sur la "recherche full text" car cela n'est pas très simple au départ.
Re-pub !
Merci, pour votre aide.
En fait j'avais mis 2 exemples "nan" et "ant", et effectivement ant n'est pas dans la racine, mais par contre "nan" y est, mais avec une longueur de 3 caractères.
Visiblement le lexeme de Nantes étant "nant" et pas "nan", est-il possible de diminuer la longueur de ce lexeme ? Ou bien est-ce impossible car c'est peut être en dur dans le dictionnaire ?
Si vous avez d'autres informations à ce sujet .
Merci encore.
Bonjour,
l'enregistrement de 184 MB a été supprimé en production (cela avait déjà été fait en, pre-prod), et depuis cela la commande "pg_dump" fonctionne correctement.
Merci beaucoup pour votre investissement.
Gérald LAURENT.
Bonjour,
J'aimerai avoir des informations au sujet de la recherche FULL TEXT dans Postgresql.
Par exemple, lorsque je fait une recherche dans une table pour retrouver un texte qui contient la ville de Nantes, si je fait une recherche avec 'nantes' ou 'nant' cela fonctionne, par contre si je fait une recherche avec 'nan' ou 'ant' cela ne fonctionne pas !
A priori le lexeme de Nantes serait 'nant' et pas 'nan' ou 'ant' (voir la commande SELECT * FROM ts_debug('french', 'nantes')!
Je ne sait pas si ce fonctionnement est normal, et si il existe un moyen pour contourner ce problème ?
Merci pour votre aide .
----------------------------------------------------------------------------------------------------------------------------
La version de Postgres :
Postgresql 8.3.4
----------------------------------------------------------------------------------------------------------------------------
L'ordre de création de la table :
CREATE DATABASE texto with encoding = 'UTF8';
CREATE TABLE ville (
localité text,
description text,
tsv tsvector
);
----------------------------------------------------------------------------------------------------------------------------
L'ordre de création du trigger :
CREATE TRIGGER tsvectorupdate BEFORE INSERT OR UPDATE
ON ville FOR EACH ROW EXECUTE PROCEDURE
tsvector_update_trigger(tsv, 'pg_catalog.french', localité, description);
----------------------------------------------------------------------------------------------------------------------------
L'insertion de données de tests dans la table :
INSERT INTO ville VALUES('nantes', 'la ville de nantes est en bretagne');
INSERT INTO ville VALUES('nan', 'nan est un mot');
INSERT INTO ville VALUES('ant', 'ant est un mot');
INSERT INTO ville VALUES('Mantes', 'la ville de mantes est dans les yvelines en IDF');
----------------------------------------------------------------------------------------------------------------------------
Les différentes requêtes de tests :
1 requête :
SELECT * FROM ville where tsv @@ to_tsquery('nantes');
localité | description | tsv
----------+--------------------------------------------+----------------------------
nantes | la ville de nantes est presque en bretagne | 'nant':1,5 'vill':3 'bretagn':9
2 requête :
SELECT * FROM ville where tsv @@ to_tsquery('nant');
localité | description | tsv
----------+--------------------------------------------+----------------------------
nantes | la ville de nantes est presque en bretagne | 'nant':1,5 'vill':3 'bretagn':9
3 requête :
SELECT * FROM ville where tsv @@ to_tsquery('nan');
localité | description | tsv
----------+----------------------+----------------------------
nan | nan est un mot | 'mot':5 'nan':1,2
4 requête :
SELECT * FROM ville where tsv @@ to_tsquery('ant');
localité | description | tsv
----------+----------------------+----------------------------
ant | ant est un mot | 'ant':1,2 'mot':5
Les deux premières requêtes remontent correctement la ville de Nantes, par contres les deux autres ne remontent pas la vile de Nantes !
Avec les fonctions ts_debut et ts_lexize on visualise le lexeme qui est 'nant':
SELECT * FROM ts_debug('french', 'nantes');
alias | description | token | dictionaries | dictionary | lexemes
-----------+-----------------+-------+---------------+--------------+---------
asciiword | Word, all ASCII | nantes| {french_stem} | french_stem | {nant}
SELECT ts_lexize('french_stem','nantes');
ts_lexize
---------
{nant}
(1 row)
Gérald LAURENT
Bonjour, je suis en attente de réponse de la production, mais à priori cela semble OK !
De note coté on garde encore la machine de test, donc il est encore possible de récupérer des éléments !
Et encore merci pour votre aide !
Gérald LAURENT.
A priori, avec la suppression de la rangée de 184MB, le pg_dump à l'air de fonctionner correctement, le dump
fait déjà 8GB...ce n'est pas encore terminé, mais c'est bien parti !
C'était donc bien lié a un problème de taille de ligne.
On regarde en prod si cela ne pose pas de problèmes !
Encore merci.
Gérald.
De mon coté je vais faire un "delete" sur la rangée qui fait 184MB (binary_id à 5001955) sur la base de test, et ensuite de nouveau un pg_dump !
Encore merci pour les infos !
Gérald.
Bonjour,
Merci pour ces informations
Voici le résultat de la commande :
Il n'y a pas d'enregistrement qui dépasse 250MB, par contre, il y en a un qui fait 184MB !
pbpgdump=# \d wct_binary
Table "public.wct_binary"
Column | Type | Modifiers
-----------+---------+-----------
binary_id | integer | not null
data | bytea |
pbpgdump=# SELECT binary_id, octet_length(data) as taille FROM wct_binary WHERE octet_length(data)>250000000 ORDER BY 2 DESC;
binary_id | taille
-----------+--------
(0 rows)
pbpgdump=# SELECT binary_id, octet_length(data) as taille FROM wct_binary WHERE octet_length(data)>25000000 ORDER BY 2 DESC;
binary_id | taille
-----------+-----------
5001955 | 184678586
5002608 | 59518226
4481757 | 55249267
4386235 | 42001376
4260858 | 26941440
4104903 | 26091548
(6 rows)
Gérald
Bonjour,
Je suis désolé pour le temps qui est passé, mais nous avons monté un serveur spécialement pour reproduire le problème !
Les nouveaux essais sont réalisés sur une SLES10 et Postgres 8.3.3.
Le problème se reproduit avec une version plus récente de Postgres, la 8.3.3 !
La table wct_binary a été chargée avec la commande COPY FROM sans erreurs !
------------------------------------------------------------------------------------------------------------
1 ESSAI
------------------------------------------------------------------------------------------------------------
1 J'ai utilisé le fichier de configuration postgresql.conf crée par défaut dans la version 8.3.3 !
2 J'ai lancé la commande : pg_dump -Fc -b pbpgdump >exp-wct-binary1.dmp
Et au bout de 1h15mn l'erreur suivante apparaît :
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: out of memory
DETAIL: Failed on request of size 539138274.
pg_dump: The command was: COPY public.wct_binary (binary_id, data) TO stdout;
Le fichier fait 3,8GIGA !
-rw-r--r-- 1 postgres postgres 3822203378 2008-10-15 15:20 exp-wct_binary1.dmp
------------------------------------------------------------------------------------------------------
2 ESSAI
------------------------------------------------------------------------------------------------------
1 J'ai utilisé le fichier de configuration postgresql.conf du client, celui de la version 8.0.3 !
2 J'ai lancé la commande : pg_dump -Fc -b base1 >exp-wct-binary2.dmp
Et au bout de 20mn l'erreur suivante apparait :
pg_dump -Fc -b pbpgdump > exp-wct_binary2.dmp
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: out of memory
DETAIL: Failed on request of size 268435456.
pg_dump: The command was: COPY public.wct_binary (binary_id, data) TO stdout;
Le fichier fait 0,9GIGA
-rw-r--r-- 1 postgres postgres 937695311 2008-10-15 16:42 exp-wct_binary2.dmp
-----------------------------------------------------------------------------------------------------------------------------
Donc, à priori il semble que la table n'ait pas de corruptions, puisque cela se plante à des endroits différents !
Ensuite cela ressemble à un problème de mauvaise gestion de ressources puisque, en fonction de fichier postgresql.conf utilisé
le delais pour que le plantage arrive différe (et aussi la taille du fichier dump) !
J'ai fait deux fois les mêmes éssais et, a chaque fois les tailles des fichiers sont identiques !
-rw-r--r-- 1 postgres postgres 3822203378 2008-10-15 15:20 exp-wct_binary1.dmp
-rw-r--r-- 1 postgres postgres 937695311 2008-10-15 16:42 exp-wct_binary2.dmp
-rw-r--r-- 1 postgres postgres 937695311 2008-10-15 17:08 exp-wct_binary3.dmp
-rw-r--r-- 1 postgres postgres 3822203378 2008-10-15 18:54 exp-wct_binary4.dmp
J'ai regardé la différence entre les deux fichiers de configuration postgresql.conf au niveau du paragraphe
RESOURCE USAGE
------------------------------------------------------------------------------------------------------------------------------
1 ESSAI : Cas plantage au bout de 1h15mn et le fichier dump de 3,8GB avec fichier postgresl.conf crée par défaut:
#-------------------------------------------------------------------------------
# RESOURCE USAGE (except WAL)
#------------------------------------------------------------------------------
# - Memory -
shared_buffers = 32MB # min 128kB or max_connections*16kB
#temp_buffers = 8MB # min 800kB
#max_prepared_transactions = 5 # can be 0 or more
#work_mem = 1MB # min 64kB
#maintenance_work_mem = 16MB # min 1MB
#max_stack_depth = 2MB # min 100kB
max_fsm_pages = 204800 # min max_fsm_relations*16, 6 bytes each
#max_fsm_relations = 1000 # min 100, ~70 bytes each
#max_files_per_process = 1000 # min 25
#shared_preload_libraries = '' # (change requires restart)
#vacuum_cost_delay = 0 # 0-1000 milliseconds
#vacuum_cost_page_hit = 1 # 0-10000 credits
#vacuum_cost_page_miss = 10 # 0-10000 credits
#vacuum_cost_page_dirty = 20 # 0-10000 credits
#vacuum_cost_limit = 200 # 1-10000 credits
#bgwriter_delay = 200ms # 10-10000ms between rounds
#bgwriter_lru_maxpages = 100 # 0-1000 max buffers written/round
#bgwriter_lru_multiplier = 2.0 # 0-10.0 multipler on buffers scanned/round
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2 ESSAI : Cas plantage au bout de 20mn et le fichier dump de 0,9GB, avec fichier postgresql.conf du client de la version 8.0.3:
#---------------------------------------------------------------------------
# RESOURCE USAGE (except WAL)
#---------------------------------------------------------------------------
shared_buffers = 42000 # min 16, at least max_connections*2, 8KB each
work_mem = 250000 # min 64, size in KB
maintenance_work_mem = 500000 # min 1024, size in KB
#max_stack_depth = 2048 # min 100, size in KB
max_fsm_pages = 250000 # min max_fsm_relations*16, 6 bytes each
max_fsm_relations = 12000 # min 100, ~50 bytes each
#max_files_per_process = 1000 # min 25
#preload_libraries = ''
#vacuum_cost_delay = 0 # 0-1000 milliseconds
#vacuum_cost_page_hit = 1 # 0-10000 credits
#vacuum_cost_page_miss = 10 # 0-10000 credits
#vacuum_cost_page_dirty = 20 # 0-10000 credits
#vacuum_cost_limit = 200 # 0-10000 credits
#bgwriter_delay = 200 # 10-10000 milliseconds between rounds
#bgwriter_percent = 1 # 0-100% of dirty buffers in each round
#bgwriter_maxpages = 100 # 0-1000 buffers max per round
------------------------------------------------------------------------------------------------------------------------------------------
Diverses informations :
------------------------------------------------------------------------------------------------------------------------------------------
La table à deux champs :
Create table wct_binary(
binary_id integer NOT NULL,
data bytea);
------------------------------------------------------------------------------------------------------------------------------------------
La commande: > select binary_id from wct_binary ne pose pas de problème !
------------------------------------------------------------------------------------------------------------------------------------------
# select count(*) from wct_binary;
count
-------
53467
(1 row)
------------------------------------------------------------------------------------------------------------------------------------------
> free
total used free shared buffers cached
Mem: 365020 360396 4624 0 2912 17056
-/+ buffers/cache: 340428 24592
Swap: 554200 370592 183608
------------------------------------------------------------------------------------------------------------------------------------------
> ulimit -a (en étant le user postgres)
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
pending signals (-i) 2912
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 2912
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
-------------------------------------------------------------------------------------------------------------------------------------------
Si vous avez d'autres idées pour faire avancer le problème.....(modifications de paramètres etc...)
Merci encore pour votre aide !
Pages : 1
