Vous n'êtes pas identifié(e).
Pages : 1
2ndQuadrant est la plus grande équipe de contributeurs techniques au projet PostgreSQL, et met en œuvre un modèle économique basé sur des logiciel libre. Nous nous appuyons sur notre excellence technique, pas sur des objectifs de vente.
Notre modèle Open-Source fonctionne très bien pour nos clients comme pour notre équipe et nous opérons localement dans le monde entier. Nos collaborateurs couvrent de nombreux fuseaux horaires, différents caractères et différentes cultures.
Notre succès nous permet de nous agrandir et de créer les postes suivants au second semestre 2013 en France :
* Administrateurs de base de données PostgreSQL, à distance et en support, géolocalisation au choix, français et anglais courant.
DBA expérimenté capable de travailler en équipe pour fournir des systèmes sécurisés à hautes-performances et haute-disponibilité.
* Consultants PostgreSQL, pays francophones, français courant.
Consultant senior expérimenté capable de se rendre en clientèle pour des prestations d'expertise, de développement et de formation.
Nous recherchons des personnes qui connaissent bien PostgreSQL et qui souhaitent encore mieux le maîtriser. Il y a plusieurs aspects à cela et nous sommes particulièrement intéressés par les domaines suivants : architecture logicielle, performance, sécurité, GIS, gestion de projet.
Les postes ouverts demandent un bon niveau en anglais parlé et écrit, la capacité de collaboration avec une équipe internationale est également essentielle.
Notre activité principale consiste à traduire notre excellence technique en un service excellent pour nos clients. Cela signifie que nous nous attendons à ce que vous ayez un haut niveau de compétences, sans toutefois être contraignant quant à vos compétences scolaires ou le nombre de vos années d'expérience. Sachez simplement que la plupart des collaborateurs de 2ndQuadrant en sont au moins à leur troisième poste et ont une vision large de la vie professionnelle et de l'industrie.
Si vous êtes intéressés par une carrière au sein d'une équipe suivant un modèle d'entreprise Open-Source, contactez-nous. Nous apprécions crédibilité, honnêteté, responsabilité, excellent travail, travail en équipe, courage, humilité, temps libre, familles, amis, et être payé équitablement pour nos contributions fructueuses.
Tous les postes sont ouvert à plein temps, des demandes pour des temps partiels sont bienvenues ; cependant nous ne sommes pas un réseau et nous ne recherchons pas d'associés, nous recrutons les prochains membres de notre équipe.
2ndQuadrant est auto-financé et croît de manière organique et durable à mesure que nos services PostgreSQL deviennent populaires.
Pas d'agences, de cabinets de placement ou de recruteurs, svp. Merci d'adresser votre CV à jour et détaillé à contact(at)2ndQuadrant(dot)fr(dot)
Nous attendons votre candidature avec impatience,
Elle est stable et distribuée en "release candidate". Ce qu'il manque c'est la documentation, tu es le bienvenue si tu veux nous aider (je sais c'est facile et tu as d'autre chats à fouetter, mais je pouvais pas m'en empêcher) 
Il faut en réalité que le paramétrage client_encoding soit réglé à la bonne valeur, c'est à dire qu'il doit correspondre à l'encodage utilisé par l'application. Chaque application peut le régler différemment si nécessaire.
http://docs.postgresqlfr.org/9.0/runtim … t-encoding
http://docs.postgresqlfr.org/9.0/multibyte.html section 22.2.3
La valeur par défaut du client_encoding est l'encodage de la base de données, ici UTF-8, d'où vos messages d'erreur.
Ah pardon, je travaille trop sur Skytools 3, qui dispose de cela.
As tu essayé de jouer avec le read-ahead? blockdev --setra 8192 /dev/sda fait souvent des merveilles. Attention toutefois au dimensionnement du read-ahead en fonction des capacités des disques.
Plus de détails dans le livre de Greg Smith :
Pour avoir les avantages de Slony sans la complexité d'administration, il existe Londiste, des Skytools
Si je comprends bien le problème, il s'agit de charger certaines données depuis un fichier XML. J'aurais utilisé la technique suivante puis un traitement avec les fonctions XML de PostgreSQL, ou bien du plpythonu (ou plperlu si cela vous convient mieux) :
Bonjour,
Je tombe un peu tard sur cette question, mais comme j'avais rédigé un article sur le sujet je me permets de le proposer, ainsi que le suivant à ne pas louper :
http://tapoueh.org/blog/2011/08/18-echa … haine.html
http://tapoueh.org/blog/2011/09/07-evit … s-sql.html
S'il s'agit comme je le pense de mettre au point un premier niveau de filtre dans la requête SQL, alors je conseillerais d'utiliser pg_trgm. Bon il se trouve que sa version en 9.1 est particulièrement adaptée, mais même dans les versions précédentes cela devrait être d'une grande aide.
http://docs.postgresqlfr.org/9.1/pgtrgm.html
Note: gleu, il est assez pénible de naviguer vers cette page depuis http://docs.postgresqlfr.org/9.1/contrib.html, ne devrait-il pas y avoir un menu des sections dans l'annexe à cette URL?
Je pense que l'outil xlogdump peut vous aider.
https://github.com/snaga/xlogdump/
https://github.com/snaga/xlogdump/blob/ … E.xlogdump
Je ne comprends pas la question, en general on stocke dans ce genre de cas la representation des nombres.
Quel est le besoin?
Pages : 1
