Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#26 Re : Général » Locale et tri » 25/11/2010 12:14:42
Je suis bien d'accord, c'est un pis-aller.
Mais, à l'époque où j'avais également des problèmes liés aux tris, ça m'a bien dépanné.
Et puis, je me trompe peut-être mais, dans des cas réels, souvent, on cherche à remonter un nombre d'enregistrement "raisonnable" et, dans ce cas, je suppose que le WHERE reste plus déterminant que le ORDER BY et peut dans ce cas continuer à exploiter les index.
#27 Re : Général » Locale et tri » 25/11/2010 10:38:00
Bonjour,
Ayant été dans ce cas avant de tout migrer en PostgreSQL 9 (franchement, ça vaut le coup de réfléchir à une migration, et d'en profiter pour "basculer" en UTF8), j'avais adopté la stratégie suivante:
Création d'une fonction
CREATE OR REPLACE FUNCTION majuscule(character varying)
RETURNS character varying AS
$BODY$SELECT UPPER(TRANSLATE($1,'ÉÈÊËéèêëàâùüçôîï','eeeeeeeeaauucoii')) AS RESULT$BODY$
LANGUAGE sql IMMUTABLE;
Et la requête devient alors
select col1, col2 from testtri order by majuscule(col2);
#28 Re : Général » Recherche plein texte et accents » 10/11/2010 15:30:41
Bonjour,
Ce n'est pas une question, mais juste un commentaire:
Je viens de migrer ma base en PostgreSQL 9, et le module unaccent marche merveilleusement bien. En plus -ce qui ne gâche rien- il est extrêmement simple d'intégrer une recherche insensible aux accents, ce qui est beaucoup plus conforme aux usages habituels des internautes.
Donc un grand MERCI à tous les développeurs PostgreSQL (et bien entendu, aux "maitres" de ce forum)
Seule information importante (a priori non indiqué dans la documentation):
Pour utiliser ce module, la base doit OBLIGATOIREMENT est encodée en UTF8.
Il semblerait en effet que la fonction ne "supprime" pas les accents pour tout autre encodage, ce qui, dans des cas comme le nôtre, nécessite une certaine vigilance lors de la phase de migration.
Ca aura été pour moi l'occasion de découvrir le SET CLIENT_ENCODING.
Encore merci à tous,
Jérôme
#29 Re : Général » PostgreSQL 9 et les BLOBS (bytea) » 09/11/2010 18:05:45
Je suis d'accord, ce n'est pas élégant... mais suffisant pour constater que les résultats diffèrent.
En théorie, je ne devrais pas avoir besoin du tout d'éditer les résultats, un simple cmp suffit.
Ce que je voulais exprimer, maladroitement j'en conviens, c'est qu'en fonction de l'utilisation ou non de la fonction encode, j'obtenais des résultats différents mais jamais celui souhaité !
Mais bon, ce n'est pas très grave, puisque le problème est simplement résolu en modifiant le postgresql.conf
Cependant, pour ma culture, j'aurai aimé comprendre; a priori, je pense que l'ajout était toujours bon (avec ou sans encode), mais je ne n'ai visiblement pas su trouver la bonne séquence pour le SELECT.
#30 Re : Général » PostgreSQL 9 et les BLOBS (bytea) » 09/11/2010 15:41:11
Merci pour votre réponse.
J'étais effectivement passé à côté de ce point.
Cependant, l'utilisation de ces nouvelles fonctions encode et decode doit quelque peu m'échapper; j'ai en effet modifié ma requête
SELECT vignette FROM table_vignette WHERE...
en
SELECT encode(vignette,'escape') FROM table_vignette WHERE...
L'image (éditée sous vim) que j'essaye d'injecter dans PostgreSQL a la forme suivante (extrait du début - en réalité, contient des caractères non imprimables):
GIF89ax^@x^@÷^@^@ò÷ý^@^@^@ßêøÐÁÄ«±|ioÓÅÌßÉÕa^@9Y^@8Á¯º~W~O~TØÍÕÍÀÊÔÈÑ716´¢±ÕÉÓÏÃͬ~X©Ê»ÈȺÆ×ÐÖÖÏÕÓÌÒNF
alors que le résultat du SELECT me donne:
GIF89ax\000x\000\367\000\000\362\367\ (sous forme de caractères imprimables)
C'est certes plus proche du "bon" résultat, car le SELECT sans decode retourne:
G494638396178007800f7000
Pour info, SELECT encode(vignette,'hex') retourne quant à lui:
47494638396178007800f70000f2f7fd
Tout celà n'est pas bien grave car, effectivement, en modifiant le postgresql.conf comme suggéré (bytea_output = 'escape' ), tout est rentré dans l'ordre.
Mais bon, j'aurai aimé comprendre...
En tout cas, encore merci pour votre aide, qui m'a permis de résoudre mon problème.
#31 Général » PostgreSQL 9 et les BLOBS (bytea) » 09/11/2010 12:44:59
- jhashe
- Réponses : 5
Bonjour,
J'utilise quelques blobs dans une base PostgreSQL que je viens de migrer de la version 8.3 vers 9.0.1. Tout se passe correctement, sauf pour les blobs.
Mon code (en PHP avec ADODB) n'a pas changé d'une ligne mais il ne fonctionne plus correctement.
Pour ajouter une image, mon code est le suivant:
$strSQL= sprintf("INSERT INTO table_vignette(id_table_vignette) VALUES (%d)",$_GET['id']);
$maCnx->execute($strSQL);
$maCnx->updateBlob("table_vignette","vignette",file_get_contents($tmp),sprintf("id_table_vignette=%d",$_GET['id']));
Dans mon exemple, il s'agit d'une image GIF de 6Ko
Pour récupérer la vignette, mon code est:
$strSQL= sprintf("SELECT vignette FROM table_vignette WHERE id_table_vignettet=%d",$_GET['id']);
$rs=$maCnx->selectLimit($strSQL);
$rs->moveFirst();
$fic= CACHE_SYSTEME.time().'_'.rand(1,100).'.gif';
file_put_contents($fic,$rs->Fields('vignette'));
Génère un fichier de 13Ko (mauvais, évidemment) ???
Le même code fonctionnait parfaitement auparavant.
Le champ vignette est de type bytea, avec le mode de stockage extended (?).
Par avance, merci pour votre aide,
Cordialement,
Jérôme
#32 Re : Optimisation » Besoin d'éclaircissement sur plan d'analyse » 08/10/2010 09:02:52
L'estimation du nombre d'enregistrements retournés était bonne.
Ma question est plutôt, pourquoi il n'utilise pas l'index car, ici, cette requête mettait plus de 3 minutes pour s'exécuter (serveur bi quad-xeon avec 32Go de RAM)
(évidemment, je ne tiens pas compte ensuite du temps de lecture du recordset...)
De plus, la "vraie" requête était du style
insert into ma_table SELECT * FROM indexation.lot_index WHERE id_lot IN (167582,167586)
Je l'ai interrompue après plus de 2 heures d'exécution !
Remarque complémentaire, probablement liée; en exécutant le "SELECT * FROM indexation.lot_index WHERE id_lot IN (167582,167586)", parfois, j'obtenais un résultat, parfois un "Out of memory error" ?!?
Pour être tout-à-fait complet, j'ai modifié mon traitement, et je n'ai plus besoin des requêtes évoquées ici, mais je suis tout de même intrigué !
#33 Optimisation » Besoin d'éclaircissement sur plan d'analyse » 07/10/2010 11:21:43
- jhashe
- Réponses : 4
Bonjour,
Je rencontre une situation que je ne comprends pas:
Je veux exécuter la requête suivante:
SELECT * FROM indexation.lot_index WHERE id_lot IN (167582,167586)
La table en question possède un index sur id_lot
CREATE INDEX idx_lot_lot_index
ON indexation.lot_index
USING btree
(id_lot);
Or, le plan d'exécution de cette requête est:
"Seq Scan on lot_index (cost=0.00..397340.40 rows=22064588 width=536)"
" Filter: (id_lot = ANY ('{167582,167586}'::integer[]))"
Résultat, l'exécution de cette requête pourtant simple demande plusieurs dizaines de minutes.
Bien entendu, j'ai relancé un ANALYZE sur la table en question, sans succès.
Il y a sûrement une subtilité qui m'échappe, mais... laquelle ?
#34 Re : Général » modifier le codage d'une base de données » 01/10/2010 11:14:11
Bonjour,
Le paramètre "client encoding" fonctionne effectivement très bien :-)
Sous Windows, pour le fixer, quand on crée la connexion ODBC, il faut cliquer sur le bouton Datasource, puis sur la page 2, dans la zone Connect Setting, il suffit de rajouter SET CLIENT_ENCODING TO 'WIN1252';
En PHP, avec ADODB, après l'établissement de la connexion, il faut ajouter la ligne suivante:
$maSource->SetCharSet("WIN1252");
Bref, l'horizon s'éclaircit.
Merci pour votre aide !
#35 Re : Général » modifier le codage d'une base de données » 28/09/2010 12:44:53
Je suis sous Debian Lenny (avec un petit bout de sid pour Postgresql-9.0)
locale -a répond:
C
fr_FR.utf8
POSIX
J'ai tenté un:
create database megalis6 with owner=postgres encoding='LATIN1' tablespace=pg_default TEMPLATE template0 LC_COLLATE='fr_FR.utf8' LC_CTYPE='fr_FR.utf8';
mais j'obtiens une nouvelle erreur:
l'encodage LATIN1 ne correspond pas à la locale fr_FR.utf8
Le paramètre LC_CTYPE choisi nécessite l'encodage UTF8.
Mais votre dernier message suggère une piste plus intéressante, à savoir le "client encoding"
Les clients lourds utilisent ODBC pour accéder à PostgreSQL. Ce paramètre se configure-t-il dans la zone "Connect Settings" du driver ODBC ? (je ne vois pas d'autre endroit possible). Que faut-il y renseigner ?
De même, nos outils WEB sont développés en PHP, et utilisent la couche d'abstraction ADODB.
Savez-vous ou positionner ce paramètre ?
A titre d'exemple, voici un extrait de la connexion actuelle:
$MM_mabase_HOSTNAME = "192.168.10.199";
$MM_mabase_DATABASE = "postgres7:mabase";
$MM_mabase_DBTYPE = preg_replace("/:.*$/", "", $MM_mabase_DATABASE);
$MM_mabase_DATABASE = preg_replace("/^.*?:/", "", $MM_mabase_DATABASE);
$MM_mabase_USERNAME = "postgres";
$MM_mabase_PASSWORD = "MonMotPasse";
$MM_mabase_LOCALE = "Fr";
$MM_mabase_MSGLOCALE = "Fr";
$MM_mabase_CTYPE = "P";
$KT_locale = $MM_mabase_MSGLOCALE;
$KT_dlocale = $MM_mabase_LOCALE;
$KT_serverFormat = "%Y-%m-%d %H:%M:%S";
$QUB_Caching = "false";
#36 Re : Général » modifier le codage d'une base de données » 28/09/2010 11:07:04
Merci pour votre réponse.
Il est vrai qu'en ce qui concerne l'encodage des caractères, je suis un peu perplexe.
Certaines données sont alimentées à partir de clients lourds sous Windows (ce qui me ferait pencher pour du WINDOWS-1252), alors que d'autres sont alimentées par divers sites WEB (iso-8859-1). Mais cela n'avait jamais posé de problème jusque là.
Par contre, j'ai un soucis avec la commande SQL que vous suggérez. Lorsque je la tape, j'obtiens le message d'erreur suivant:
nom de locale 'fr_FR' invalide.
Or, vous avez raison, l'impact sur l'ordre des tris est pourtant particulièrement important.
Mais, mon problème principal provient de la contribution unaccent. Rien ne semble préciser dans la documentation qu'elle ne fonctionne qu'en UTF-8. Or cela semble malheureusement pourtant être le cas. Dans une situation comme la nôtre, où la base est en place depuis des années, est alimentée par de nombreux programmes (des clients lourds, des intranets, des sites web,...), changer le type d'encodage est quasi-impossible (il faudrait modifier tous les process "en même temps", et je ne suis même pas sûr que nous possédions les sources pour chacun d'entre eux).
Ma plus grosse attente concernant la version 9.0 de PostgreSQL concernait pourtant bien ce point fondamental (voir les nombreux messages que j'avais envoyés sur ce même forum). Nous avons en effet commencé à développer des interfaces exploitant T-Search, mais les usages en France font que les internautes "zappent" fréquemment les accents. D'ailleurs, qui accentue correctement les majuscules ? Sans unaccent, le résultat est insatisfaisant (par exemple, je recherche hôtel, mais je ne retrouve pas un article dont le titre est HOTEL DE LA MER, compréhensible d'un point de vue SGBD, mais aberrant d'un point de vue utilisateur)
On peut certes "bidouiller" en stockant une copie (ou mieux, directement le vecteur) du champ sans les accents, mais cela pose d'autres problèmes, notamment le ts_headline utilisé pour afficher des extraits de résultats. En effet, un extrait privé de ces accents est inacceptable pour nos utilisateurs.
J'essaye de me battre avec des convert_to, encode et autres manipulations, mais sans succès.
Bref, mes premières tentatives génèrent quelques frustrations (et c'est peu dire...)
#37 Re : Général » modifier le codage d'une base de données » 28/09/2010 10:19:24
Je me réponds à moi-même ;-)
Je pense avoir réussi, en exécutant la commande suivante:
CREATE DATABASE MaBase
WITH OWNER = postgres
ENCODING = 'ISO_8859_1'
TABLESPACE = pg_default
TEMPLATE template0
LC_COLLATE = 'POSIX'
LC_CTYPE = 'POSIX'
CONNECTION LIMIT = -1;
En espérant que cette information puisse être utile à d'autres.
Et merci pour votre aide, toujours aussi précieuse et avisée
#38 Re : Général » modifier le codage d'une base de données » 28/09/2010 10:16:52
Excusez-moi, vous avez raison. Le charset était mauvais.
Mon serveur WEB utilise actuellement iso-8859-1
J'ai réussi à intégrer mon dump, après l'avoir converti "à la main" en UTF8, comme ceci:
iconv -f WINDOWS-1252 -t UTF-8 -o megalis5.sql ../postgresql/megalis_last.sql
Mais, bien évidemment, l'affichage des caractères accentués devient incohérent.
Mon souhait serait donc de créer une base en définissant explicitement ce charset.
#39 Re : Général » modifier le codage d'une base de données » 28/09/2010 09:01:28
J'ai déjà essayé.
Exemple:
CREATE DATABASE mabase
WITH ENCODING='ISO_8859_5'
TEMPLATE=template0
Erreur: ERREUR: l'encodage ISO_8859_5 ne correspond pas à la locale fr_FR.UTF-8
DETAIL: Le paramètre LC_CTYPE choisi nécessite l'encodage UTF8.
Si j'en crois pgAdmin, pour Collation, j'ai le choix entre C, fr_FT.UTF8 et POSIX. Malheureusement,quelque soit le type choisi parmi ces 3, j'ai toujours la même erreur.
#40 Re : Général » modifier le codage d'une base de données » 27/09/2010 18:46:28
Bonjour,
Je souhaitais profiter de la migration vers PostgreSQL 9.0 pour (enfin !) utiliser le module unaccent.
Or, malheureusement, pour des raisons "historiques", le codage actuel de ma base est SQL_ASCII. Les commandes unaccent ne fonctionnent donc pas dessus, ce que je peux comprendre.
J'ai donc tenté de créer une base en UTF8, mais je n'arrive pas y importer mon dump (j'obtiens une suite d'erreurs du style: ERREUR: séquence d'octets invalide pour l'encodage « UTF8 » : 0xe96e6f
CONTEXTE : COPY log_user_backup, ligne 12)
J'ai tenté à partir d'un dump "simple" (pg_dump mabase) et avec la commande suggérée ci-dessus (pg_dump -Fc -f tabase.dump --encoding='UTF8' TABASE), mais rien n'y fait; j'ai toujours la même erreur.
A priori, l'encode actuel de ma base serait ISO-8859-1 (généré essentiellmement à partir de clients Windows), mais si j'essaye de créer une base avec ce type d'encodage, createdb me génère une erreur: l'encodage ISO_8859_5 ne correspond pas à la locale fr_FR.UTF-8. Le paramètre LC_CTYPE choisi nécessite l'encodage UTF8.
Mon cas est-il désespéré ?
Par avance, merci pour votre aide
#41 Re : Général » Probleme pour relancer mon serveur Postgres » 04/05/2010 09:48:28
Une erreur souvent commise au début (je suis passé par là ;-) ) est d'augmenter le nombre de sessions simultanées (max_connections). Sans précaution particulière, on aboutit alors souvent au message d'erreur cité ci-dessus.
#42 Re : Réplication » Réplication tutorial » 06/04/2010 09:51:19
Vivement sa sortie !
La roadmap prévoit malheureusement des délais qui s'allongent régulièrement quant à la date de sortie (voir ici http://www.postgresql.org/developer/roadmap.html)
Elle parlait en effet initialement du 1er trimestre, puis du 2ème, et maintenant, elle suggère que ce pourrait être pour le 3ème.
Enfin, prenons notre mal en patience, et un grand coup de chapeau à toute la communauté qui oeuvre à la réussite de ce projet magistral.
#43 Re : Réplication » Réplication tutorial » 02/04/2010 09:11:58
Personnellement, j'attends avec impatience la v9 qui, si j'ai bien compris, autorisera toujours le log shipping mais avec des réplicats (enfin !) accessibles en lecture seule. Pour une appli. comme la notre, où nous avons une seule base mais des milliers de connexions, cela semble un compromis performance/facilité d'usage idéal !
#44 Re : Réplication » Erreur CETFATAL - Warm Standby » 01/03/2010 11:12:15
Excellente nouvelle !
Je trépigne donc encore plus d'impatience.
#45 Re : PHP » Pb de communication entre php5.2 et Postgresql 8.3.8 » 26/02/2010 18:32:52
Remarque sans doute idiote, mais avec un pg_pconnect (connexion persistante) à la place de pg_connect, ça n'aiderait pas ?
Autre piste (différente au niveau de l'architecture, mais semblable au niveau de la réflexion): utiliser un pooler de connexion (pg_bouncer ou pg_pool II) ?
Je gère des sites qui voient des millions de page chaque jour. Sans les connexions persistantes, chaque script crée une nouvelle connexion à la base, ce qui a pour effet d'écrouler le serveur PostgreSQL. En évacuant ce problème, il se tourne les pouces. Et pourtant, il en exécute, des requêtes !
#46 Re : Réplication » Erreur CETFATAL - Warm Standby » 24/02/2010 12:24:28
Comme une réponse à ma question concernant la version 9.0 de PostgreSQL, une nouvelle page vient d'être publiée sur le site officiel de PostgreSQL:
#47 Re : Réplication » Erreur CETFATAL - Warm Standby » 23/02/2010 19:04:02
Merci pour ces précisions.
J'ai hâte (et nous sommes probablement nombreux dans ce cas) de voir sortir cette nouvelle version.
J'espère par ailleurs qu'elle permettra des recherches plein texte insensibles aux accents. Cet ajout avait déjà été évoqué pour la 8.4, mais malheureusement pas finalement intégré.
#48 Re : Réplication » Erreur CETFATAL - Warm Standby » 23/02/2010 12:30:22
Bonjour,
Je croyais que la version 8.5 permettrait l'utilisation de l'esclave en lecture seule.
Ce n'est pas la même chose ?
De plus, sur le site www.postgresql.org, il est annoncé que la version 8.5 est "espérée" pour le 1er trimestre 2010 (http://www.postgresql.org/developer/roadmap.html) mais on ne parle pas de version 9. Est-il possible de lever le voile sur cette annonce ?
#49 Re : Général » pgtune » 09/11/2009 13:24:33
J'ignorais tous ces points et je ne cherchais pas à polémiquer !
Je voulais juste partager mon enthousiasme pour cet outil qui peut peut-être aider à une configuration optimisée pour un serveur donné par rapport au fichier fourni par défaut, obligatoirement plus standard.
Et dans mon cas, il a positionné shared_buffers à 1920MB, ce qui correspond environ au quart de la RAM disponible (8GB).
Il me semble également, toujours pour mon cas (donc particulier...) que PostgreSQL réponde mieux et, surtout, charge moins le serveur.
#50 Général » pgtune » 06/11/2009 13:35:46
- jhashe
- Réponses : 3
Bonjour,
Je viens de découvrir dans la rubrique "Actualités" du présent site le projet pgtune.
Je n'ai pas les compétences nécessaire pour juger de la qualité des réglages qu'il propose, mais je viens de tenter sur mon serveur de production, et, ce qui est sûr, c'est qu'il fonctionne toujours.
L'outil est simplissime à "installer" (si on peut dire, puisqu'il n'y même pas d'installation) et à utiliser. Si ses réglages s'avèrent pertinents, pour tous les utilisateurs qui, comme moi, ne connaissent pas toutes les subtilités de PostgreSQL, je dis: GENIAL !!!
Toujours est-il que, sous réserve que ses propositions soient judicieuses, j'en viendrais presque à souhaiter qu'il soit ajouté aux installateurs "packagés" de PostgreSQL (setup.exe, .deb, .rpm,...) et automatiquement appelé à l'installation. Cela permettrait peut-être une fois pour toutes de tordre le cou aux commentaires du style "PostgreSQL est plus lent que..., c'est compliqué à configurer, etc)
Enfin voilà, tout cela pour partager mon premier retour sur ce petit outil qui, vous l'aurez compris, m'a plû.
Et merci à PostgreSQL.fr et toute son équipe qui non seulement de nous apporte une aide toujours efficace, mais en plus nous permet de découvrir tout l'environnement qui gravite autour de notre SGBD préféré.