Vous n'êtes pas identifié(e).
Fondée en 2010, Loxodata est une société reconnue pour son expertise autour des solutions de gestion de données PostgreSQL.
Notre offre est structurée autour de 3 piliers d’expertise : PostgreSQL, DevOps et le Cloud.
Sur ces piliers, nous avons bâti une offre de services en conseil, formation et support.
Nos clients couvrent tous les secteurs d’activité, et toutes les typologies de structures, de la start-up aux institutions.
Dans le cadre de nos missions chez nos clients, nous sommes amenés à agrandir l'équipe.
Nous recherchons 2 DBA PostgreSQL expérimentés prêts à s'investir à nos côtés sur une mission longue chez un de nos clients en région parisienne.
Intégré(e) au sein de l'équipe d'expertise SGBD de notre client, vous interviendrez sur des questions de support et de conseil aux équipes d'architecture et de production.
Vous serez accompagné sur cette mission par un de nos consultants.
La mission se déroulera en temps partagé, avec une possibilité de télétravail.
Au delà de vos compétences techniques, nous comptons sur vos qualités humaines pour prendre part à l’expansion de notre entreprise.
Vous maîtrisez a minima PostgreSQL.
Votre ouverture d'esprit vous à permis d'expérimenter d'autres types de solutions de gestion de données distribuées.
L’algèbre relationnelle n’a pas de secret pour vous. Vous parlez couramment le SQL, alors pourquoi pas l’anglais.
Vous êtes à l’aise sous Linux.
Une expérience réussie en environnement de production est un vrai plus.
Autonome, capable d’initiatives, vous avez l'aisance nécessaire pour appréhender des contextes projets très variés.
Vous détestez les réponses formatées et n’avez pas peur de poser des questions, préalable à une bonne compréhension.
Par votre engagement, vous contribuez à la cohésion de nos équipes, à la construction de notre réussite et au rayonnement de Loxodata.
Parce que l'environnement est une composante essentielle du développement des compétences, nous offrons chez Loxodata un cadre de travail idéal pour vous épanouir.
En dehors de vos interventions chez nos clients, vous pouvez travailler de chez vous.
Participant aux conférences et forums techniques du domaine, en France et à l’étranger, vous êtes acteur de la communauté.
Votre rémunération, fonction de votre profil, est évolutive.
Vos frais de déplacement, et l’accès aux conférences techniques sont pris en charge.
Enfin, vous bénéficiez d’une mutuelle très avantageuse.
Contact : jobs@loxodata.com
Fondée en 2010, Loxodata est une société reconnue pour son expertise autour des solutions de gestion de données PostgreSQL.
Notre offre est structurée autour de 3 piliers d’expertise : PostgreSQL, DevOps et le Cloud.
Sur ces piliers, nous avons bâti une offre de services en conseil, formation et support.
Nos clients couvrent tous les secteurs d’activité, et toutes les typologies de structures, de la start-up aux institutions.
Pour accompagner notre croissance, nous avons ouvert plusieurs postes de consultant(e).
Nous cherchons des contributrices et contributeurs enthousiastes pour compléter nos savoirs et progresser avec nous. Des personnes ouvertes et curieuses pour partager nos valeurs et nos services centrés sur la satisfaction du client.
Intégré(e) au sein de notre équipe de consultants, vous interviendrez sur des missions de tout type, et de différentes durées.
Parmi vos missions, outre des prestations de conseil et d’audit autour de PostgreSQL, vous aurez la charge d’accompagner nos clients dans leur prise en main de PostgreSQL.
Au delà de vos compétences techniques, nous comptons sur vos qualités humaines pour prendre part à l’expansion de notre entreprise.
Vous maîtrisez a minima un SGBD relationnel (PostgreSQL dans l’idéal), et votre ouverture d'esprit vous à permis d'expérimenter d'autres types de solutions de gestion de données distribuées.
L’algèbre relationnelle n’a pas de secret pour vous. Vous parlez couramment le SQL, alors pourquoi pas l’anglais.
Vous êtes à l’aise sous Linux. L'automatisation des tâches répétitives est pour vous une évidence. Vous savez exploiter un langage comme Go, Ruby ou Python pour vous rendre plus efficace au quotidien.
Une expérience réussie en environnement de production est un vrai plus.
Autonome, capable d’initiatives, vous avez l'aisance nécessaire pour appréhender des contextes projets très variés. Vous savez intelligemment manier la richesse des contraintes apportées par les projets de nos différents clients.
Pédagogue, et doué(e) de réelles qualités relationnelles, vous aimez partager vos connaissances, avec nos clients et vos pairs. Vous contribuez à la rédaction des supports de formation, des rapports d’intervention et d’audit.
Vous détestez les réponses formatées et n’avez pas peur de poser des questions, préalable à une bonne compréhension.
Par votre engagement, vous contribuez à la cohésion de nos équipes, à la construction de notre réussite et au rayonnement de Loxodata.
Parce que l'environnement est une composante essentielle du développement des compétences, nous offrons chez Loxodata un cadre de travail idéal pour vous épanouir.
En dehors de vos interventions chez nos clients, vous pouvez travailler de chez vous.
Participant aux conférences et forums techniques du domaine, en France et à l’étranger, vous êtes acteur de la communauté.
Votre rémunération, fonction de votre profil, est évolutive.
Vos frais de déplacement, et l’accès aux conférences techniques sont pris en charge.
Enfin, vous bénéficiez d’une mutuelle très avantageuse.
Contact : jobs@loxodata.com
En faite, je n'avais pas lancé la requête sur la bonne base. Le résultat de SELECT sum(pg_total_relation_size(oid)) FROM pg_class; est 105 487 474 688
Bizarrement, pg_total_relation_size et pg_table_size donnent le même résultat.
Ce qui signifieraient qu'il n'y a pas d'index, ni de toast.
Quel est votre OS et votre type de filesystem ?
Est-il possible que des fichiers anciens, ne correspondant plus à aucun objet de la base n'aient pas été supprimés ?
Que donne un "du -sh" sur le répertoire de la base ?
Avez-vous des fichiers surnuméraires dans ce répertoire ?
Que donne la requête suivante ?
SELECT sum(pg_total_relation_size(oid)) FROM pg_class;
Bonjour,
L'annonce ne précise pas de lieu de travail a priori.
Parce que nos clients sont situés sur l'ensemble du territoire français et certains au-delà de nos frontières.
Nous sommes amenés à nous rendre chez nos clients, et parfois à nous y installer pour quelques temps.
Le télétravail reste possible, mais les déplacements en clientèle font partie de notre quotidien.
Loxodata est une société de conseil spécialisée sur l’écosystème du SGBD PostgreSQL.
Depuis 2010, nous avons développé un savoir-faire reconnu par nos clients. Notre force est portée par les hommes qui constituent nos équipes.
Aujourd’hui le SGBD Postgresql a le vent en poupe et présente une alternative probante face à des systèmes propriétaires onéreux.
Nous recherchons actuellement des profils capables de nous accompagner dans notre croissance.
Parce que nous privilégions les hommes et les relations techniques durables avec nos clients, vous pourrez vous investir sur des projets intéressants.
Vous serez amené à intervenir sur l’ensemble des typologies de services proposées par loxodata.
L’accompagnement que nous proposons à nos clients est un panel de services comprenant la définition d’architecture technique, la mise en place de bonnes pratiques, l’administration des bases de données, le support et la formation.
Ayant un profil d’administrateur de bases de données avec 5 ans d'expériences, vous êtes curieux et vous assurez une veille technologique active dans votre domaine.
Vous apportez un conseil en cohérence avec l’état de l'art que recherchent nos clients répartis sur l’ensemble du territoire Français, et au-delà.
Vous participez en interne à la construction d’outils innovants aidant à garantir la qualité de nos services.
Nous engageons des gens éveillés et pertinents, forces de proposition, qui sauront nous indiquer la meilleure voie à suivre dans l’intérêt de l’entreprise.
Si ce challenge vous intéresse et que vous souhaitez partager nos valeurs, prenez le temps d'en discuter avec nous.
Merci d'adresser votre dossier de candidature à recrutement.
Bonjour,
(Je ne sais pas si votre demande ne concerne que la recherche d'un ouvrage ou si vous souhaitiez des éclaircissements sur les différences de performances entre vos deux bases.)
Il existe quelques ouvrages pour débuter avec PostgreSQL.
Ceux en français sont rares, mais il en existe tout de même quelques-uns.
Le plus récent, et qui constitue une très bonne référence est celui de Sébastien Lardière :
http://www.editions-eni.fr/livres/postg … 37ba6.html
Bonjour,
Vous ne précisez pas le lieu de la formation.
Ni le moyen de vous contacter.
S.
Bonjour,
PostgreSQL répond exactement à vos critères :
- libre, ouvert, gratuit
- tourne sous Unix, Linux, et énormément d'autres OS
- il est possible de définir des critères très fins d'accès aux données (lignes, colonnes, rôles)
- robuste et performant
- plusieurs To de données ne lui font pas peur
- sauvegarde à chaud
- PITR, haute-disponibilité
...
Bon, après avoir transformé toutes les majuscules en minuscules, CA MARCHE !!
... je retiens qu'il ne faut jamais mettre de majuscule quand on utilise postgresql.
Bonjour,
Ce n'est pas tout à fait cela.
Il se trouve que PostgreSQL considère des minuscules _par défaut_.
Cela signifie que si vous utilisez des majuscules, il faudra toujours veiller à bien entourer la chaîne de caractères représentant le nom de l'objet de double quotes dans TOUTE référence à l'objet. Dans votre code, dans le SQL...
Cela dit, je ne comprend pas pourquoi l'erreur intervient en plein milieu de l'insertion et non pas dès le début, si ce n'est lié qu'à une mauvaise identification des objets.
Re-bonjour,
Il manque des informations dans votre rapport.
Et votre schéma n'est pas correct.
Je vous conseille d'éviter fortement les majuscules dans les noms de tables et de champs. Elles n'apportent que complexité et ennui.
Pouvez-vous donner un exemple de ligne CSV ?
Importez-vous le CSV tel qu'il est, ou le traitez-vous avec votre programme ?
CP n'est pas un integer, mais plutôt une chaîne de caractères, de 5 caractères. Avec un entier, toutes les villes comprises dans les départements 01 à 09 n'auront que 4 chiffres sur le code postal. Ce qui n'est pas satisfaisant.
Avez-vous la certitude que 50 est la limite de longueur des noms de ville ?
"syntaxe en entrée invalide pour l'entier : 1/2 5700" <-- Il y a 1/2 dans le CSV ?
Bonjour,
Pouvez-vous préciser le schéma de la table ?
Bonjour,
Pouvez-vous indiquer le lieu d'exécution de cette mission ?
Cela pourrait faciliter les réponses.
Ce thread nous en apprend beaucoup plus sur les différents intervenants que sur PG lui-même, il me semble ;-)
Bonjour,
Le return NULL; de votre fonction vous oblige à la quitter avant le select et l'update, il me semble.
Vous pourriez envisager un trigger qui ne prenne pas en compte les champs interdits.
Ou plus simplement ne pas inclure les champs dans la commande d'insert/update.
Vous pouvez aussi créer une table d'historisation sous la forme
Table_origine|type_mod|date_heure
Machin | I | default now()
Machin | U | default now()
Avec des triggers sur les tables qui déclenchent les insertions dans la table d'historisation.
Bonsoir,
Vous pouvez envisager l'écriture d'un trigger *before* qui vérifie que vous ne ne modifiez pas la valeur du champ interdit. Si tel était le cas, vous sortez en erreur de la fonction appelée par le trigger.
(Juste un petite remarque, en passant.)
Vous pouvez aussi utiliser l'opérateur ilike, qui lui est insensible à la casse.
Bonjour,
La clause EXCEPT n'est pas optimisée.
La première requête est évaluée, et le résultat de la seconde lui est soustrait.
Dans votre premier cas, on obtient le résultat de la vue 1 moins le résultat de la vue 2.
Dans le second cas on évalue d'abord la seconde vue, puis la première.
C'est de la théorie des ensembles, pas de l'algèbre.
Il n'y a a priori pas de raison d'espérer que l'opération soit commutative.
Bonjour,
Je ne vois pas le lien entre les superutilisateurs et le group AD...
Vous devriez peut-être fournir la totalité du fichier pg_hba.conf.
Un problème de stats, ou une répartition à ce point particulière que le plan diffère grandement.
Tout le reste est identique ? Index, schémas...
Le département a-t-il une particularité ?
Une répartition ou une volumétrie différente ?
Il est des commentaires dont on se passerait volontiers.
Bonjour,
Qu'entendez-vous pas réindexer une table à partir de 1 ?
Bonjour,
Un ETL (https://fr.wikipedia.org/wiki/Extract_Transform_Load) est probablement l'outil que vous cherchez.
Vous pouvez regarder du côté de Talend (http://www.talend.com/).
