Vous n'êtes pas identifié(e).
Bon, je ne connais pas trop les règles (c'est le genre de trucs interdits dans les projets pour lesquels je travaille habituellement, bref.). J'espère que quelqu'un de plus compétent saura te répondre.
Par contre, attention avec le fait de créer la ligne si elle n'existe pas : il faut penser à gérer les conflits éventuels si 2 personnes font la même requête (ou à ne pas gérer, mais seulement en parfaite connaissance de cause, après s'être assuré que cela ne détruit rien et que l'utilisateur ne perdra pas trop de travail)
Pourriez-vous donner la définition précise des 2 tables (les ordres de création par exemple) ?
C'est ce problème que vous essayez de résoudre, non? : http://fr.wikipedia.org/wiki/Probl%C3%A … e_commerce
pg_ctl reload est une commande, pas un fichier
http://docs.postgresqlfr.org/9.1/app-pg-ctl.html
Si vous avez redémarré le serveur, normalement les modifications sont prises en compte.
Avez-vous rechargé la configuration (pg_ctl reload , ou redémarage du serveur) ?
Tout est expliqué ici : http://docs.postgresqlfr.org/9.1/runtim … gging.html
Sinon, pour aller vite, si tu veux loguer les requêtes SQL, il faut mettre log_statement à 'all'.
Si tu as plusieurs utilisateurs, log_connections et log_disconnections sont utiles....
Enfin, n'oubliez pas de recharger la configuration :
envoi d'un SIGHUP à postmaster, ou bien pg_ctl reload :
http://docs.postgresqlfr.org/9.1/app-pg-ctl.html
c'est la commande que rjuju vous a donnée le 5 octobre.
Lancez-la en remplaçant le chemin du répertoire data par le chemin actuel.
Si c'est juste pour apprendre à l'utiliser (créer des tables, écrire des requêtes, gérer les utilisateurs), je pense que
Windows est largement suffisant. Ça vous prendra moins de temps, à moins que vous connaissiez très bien Linux et pas du tout Windows.
Personnellement, j'ai dû faire la même chose il y a quelques années (installer une base pour apprendre à m'en servir, dans le but de monter une formation Java...). Bien que n'étant pas (mais alors pas du tout) fan de Windows, j'ai fini par installer ma base sous Windows (poste de travail pro sous Windows). Parce que c'était plus simple (pas besoin de serveur distant, ni de monter une machine virtuelle qui bouffait mes ressources système).
Enfin, c'est vous qui voyez.
Si vous avez des questions sur des concepts que vous ne comprenez pas, demandez...
Si vous ne connaissez pas du tout les bases de données relationnelles, je vous conseille de vous procurer un livre. J'avais vu celui-là qui a l'air pas mal :
http://www.google.com/url?sa=t&rct=j&q= … -6imAvu6kw
mais il semblerait qu'il vaut mieux connaître un petit peu le SQL avant de commencer.
Je ne peux vous conseiller de livre pour débutant total, ceux que je connais s'adressent à des connaisseurs, ou des étudiants très motivés (ils sont très théoriques)
Sinon, dans la documentation de PostgreSQL, il y a un tutoriel :
http://docs.postgresql.fr/9.2/tutorial-sql.html
Il n'est pas mal fait, vous pouvez sans doute débuter avec.
Ce qui vous coûte cher dans ce plan, c'est le parcours d'index. C'est lui qui prend pratiquement tout le temps de la requête. Il y a de fortes chances que ce soit dû à un cache trop petit. Un cache de 16 Mo sur une machine qui a 32 Go de RAM, c'est assez marrant, mais pas très sérieux
Généralement, sur un serveur dédié avec une instance PostgreSQL, on met 1/4 de la mémoire. Sans aller jusque là, PostgreSQL gagnerait à avoir plus de RAM. 4 Go par exemple. N'oubliez pas de vérifier vos paramètres noyaux shmmax et shmall avant de redémarrer PostgreSQL.
Il semblerait qu'on est au moins 3 à être d'accord sur le fait qu'il faut fortement augmenter le paramètre shared_buffers pour le passer à 4Go, voire 8 Go... On attend le résultat de l'opération!
Si on suppose que le modèle est bon,
en fait le plan ne me paraît pas déconnant : on a d'un côté une table pi, filtrée par la condition AND, et il reste 10839 lignes filtrées.
En face, la table ln_pi fait 5 millions de lignes apparemment. Donc elle est beaucoup plus grosse.
Si on regarde l'index scan sur ln_pi, c'est bien cela qui prend le plus de temps (15 ms par accès, multiplié par 10 800 lignes....).
Essayez donc ce que conseille rjuju et kenrio (augmenter shared_buffers ), ça pourrait changer la donne...
Bonjour benclaff,
la table ln_putative_inparalog_sequence n'a pas de clé primaire, ce qui veut dire qu'il y a un problème de modélisation quelque part.
Ne connaissant pas le domaine, je ne comprend pas comment le corriger. Notamment quel est le lien entre ln_putative_inparalog_sequence et putative_inparalog?
Vu les noms et la stucture, il semblerait que c'est une table de lien entre sequence et putative_inparalog? Une séquence ayant plusieurs "putative_inparalog" et chaque "putative_inparalog" étant lié à plusieurs séquence???
Mais dans ce cas, pourquoi pk_sequence est-il dans putative_inparalog??? (la table ln_putative_inparalog_sequence ne sert à rien si putative_inparalog correspond directement à une séquence, et que c'est la même séquence)
Et est-ce qu'une séquence peut faire partie de plusieurs "putative_inparalog"?
Pourriez-vous donc essayer d'expliquer un peu mieux les relations entre ces 3 tables?
D'autre part, des tables contiennent des colonnes pk_version. À quoi cela correspond-il?
Je ne vois pas de clé primaire dans les définitions. Elles sont où?
De plus, qu'est-ce que cela représente?
J'ai l'impression que le modèle n'est pas bon : à quoi sert la 2ème table (ln_putative_inparalog_sequence ). Que représente sequence? Est-ce le même pour les 2 tables?
(je pense que les index ne sont pas les bons, mais pour cela il faut comprendre ce que représentent les tables)
Pourrais-tu donner la définition des tables utilisées dans la requête, et en particulier les clés primaires et les index?
D'autre part, un explain analyze donne plus d'informations qu'un simple explain. Pourrais-tu en fournir un?
On dirait qu'il manque un index sur tables_adresses.adresses_01.id
Ça permettrait déjà d'éviter la lecture séquentielle de tables_adresses pour ne ramener que 2924 lignes pour la première requête et... zéro pour l'autre.
On peut toujours les rediriger ici. C'est moins fatiguant que de leur écrire une petite bafouille personnalisée.
Certains posts sur le forum ne comportent ni ponctuation, ni syntaxe correcte. Cela est extrêmement pénible à lire. Personnellement, je renonce à les lire. Et tant pis si j'aurais pu aider ces personnes : j'ai autre chose à faire que de décoder.
Je ne parle bien entendu pas des posts qui sont manifestement écrits par une personne dont le français n'est pas la langue maternelle, ni des messages comportant quelques fautes d'orthographe ou de grammaire. Mais des posts qui sont écrits sans le moindre effort pour le lecteur, sans ponctuation, sans grammaire. Ceux-là sont vraiment trop pénibles à lire pour mériter l'effort.
Je suppose que je ne suis pas la seule à renoncer dans ce cas.
Je conseille donc vivement à tout le monde de :
1. faire des phrases (avec la ponctuation appropriée)
2. se relire afin de vérifier que les phrases en question sont compréhensibles (simplifier éventuellement),
3. passer éventuellement le texte au vérificateur d'orthographe.
Florence.
NB : je comprends qu'il y ait des personnes qui aient des problèmes avec l'orthographe ou la grammaire. Mais faire des phrases est à la portée de tous (Commencer par une majuscule, finir par un point). Se relire aussi. Et pour ceux qui savent qu'ils ont un problème avec la grammaire ou l'orthographe, passer le texte au vérificateur orthographique pour diminuer le nombre d'erreurs ne coûte pas très cher, et est un bonus appréciable.
Vous faites l'effort que vous estimez nécessaire, mais pour ma part je ne lirai plus les messages de ceux qui demandent de l'aide, et ne font même pas au moins l'effort d'être compréhensibles.
D'autre part, je mets ce message ici car cela ne me semble pas approprié dans "général", vu qu'il ne s'agit pas de PostgreSQL, et que répondre personnellement en public aux messages en question me semble brutal envers leur auteur (et hors sujet).
votre table échantillonnage sera pleine mais la table mammifère vide ?
Si c'est ça, je fais une procédure stockée, qui quand je la lance regarde le nombre de mammifère et insert le nombre de ligne avec une boucle et donc tous les autres champs vide ou avec un default.
mais c'est un oneshot par contre
Cela n'a aucun sens de créer des lignes vides. Ou même juste avec un identifiant (une clé primaire).
J'ai vraiment l'impression qu'on met la charrue avant les boeufs : on cherche une solution à un problème technique tordu pour résoudre un problème réel qu'on ne connaît pas. ("on" = les personnes qui essaient d'aider)
hmahe44, pourquoi voulez-vous faire cela?
Et comment sera remplie la table "mammifere"? (à quel moment, et à partir de quelles données?).
Tant que vous ne répondrez pas à ces questions, nous allons tourner en rond, proposer des solutions complexes que vous aurez du mal à mettre en oeuvre et qui ne répondront pas, ou mal, à votre besoin.
Vous êtes débutante apparemment, ce qui explique que vous ne voyiez pas en quoi c'est tordu d'utiliser la base de cette manière. Il n'y a rien de mal à cela, mais s'il vous voulez qu'on vous aide, répondez à toutes les questions qu'on vous pose. Vous n'avez pas répondu à ma question de tout à l'heure.
Et faites attention également à mettre des points à la fin des phrases, et des majuscules au début : cela rend la lecture nettement plus facile. Merci.
C'est plus compréhensible.
Mais quel est l'intérêt de créer des lignes dans la table "mammifère"? Quelles valeurs voulez-vous mettre dans ces lignes au moment où vous les créez ?
Ce n'est pas un bug de Perl a priori, c'est que vous avez un caractère qui ne fait pas partie du jeu de caractères UTF-8.
Vous êtes certains que la base Oracle est en AL32UTF8?
Si vous faites la requête :
SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET' ;
Cela donne quoi?
Et en travaillant sur les logs? (en loguant tous les ordres SQL et en passant dessus un script ou un programme)
La difficulté que je vois ce sera le volume de log généré (suivant l'activité de la base) et comment gérer les compteurs et les fichiers de log pour ne pas relire à chaque fois les fichiers.
Mais sinon, au niveau applicatif, si c'est possible c'est sans doute le plus simple (si une seule application, et qu'il y a une couche d'accès qui va bien)
on ne peut pas paralléliser suivant les lignes de la table A, les deux process doivent chacun lire toutes les lignes de cette table.
ce que je me demande c'est :si je faits LOCK TABLE A IN SHARE ROW EXCLUSIVE MODE
1. Est-ce-que une autre transaction peut écrire dans la table A.
D'après http://www.postgresql.org/docs/9.1/stat … PATIBILITY, il semble que non (la modification essaiera d'acquérir un verrou ROW EXCLUSIVE)
2. Est-ce-que une autre transaction peut lire les lignes de la table A
oui
3. est-ce-que toute la table est verouillée ou bien seules les lignes updatées par ma transaction sont verouillées.
Toute la table
4. En quoi les perfs sont impactées (exemple????).
Simplement, vu que le verrou posé par la 1ère transaction est incompatible avec une modification, il faudra que la 2ème transaction attende la fin du traitement (le COMMIT ou le ROLLBACK) de la 1ère pour pouvoir mettre à jour la table A.
De toute manière, vu que vous travaillez sur les mêmes lignes, il n'y a pas de solution qui permette de paralléliser les mises à jour sur la table A.
D'où ma proposition de modifier la conception...
C'est donc bien ce que je pensais : la parallélisation n'est pas faite suivant les bons critères.
Il vaudrait mieux paralléliser suivant les lignes de la table A. Comme cela, pas de mises à jour concurrentes entre les transactions, et pas besoin de faire des locks qui rendraient la parallélisation inutiles.
En plus, d'un point de vue de développeur, c'est bien plus souple (il est facile de changer le critère de découpage des lignes de A, voire supprimer la parallélisation si cela s'avère plus efficace au final).
Au passage, A, B et C sont bien dans la même base?
Il me semble que dans vos traitements, vous partez de la table A pour créer des enregistrements dans des tables B et C (à partir des données de A, donc).
Les 2 transactions sont en parallèle : pourquoi?
Et une fois les lignes créées, on met des indicateurs dans la table A pour signifier que les lignes ont été traitées.
Si c'est bien cela, il y a un problème de conception générale. Il faudrait faire les écritures dans B et C l'une après l'autre.
Ou si vous voulez paralléliser les écritures, trouver un critère qui permette de distinguer les lignes de la table A pour les traiter en parallèle, mais chaque traitement se fera sur des ensembles disjoints de lignes de la table A. Par contre les écritures dans B et C seraient en séquence.
Personnellement, je pense que tout cela est bien compliqué et surtout je ne comprends absolument pas votre besoin de "convertir" l'index en base64, et de le stocker. Si l'index_base64 est calculé à partir de l'index, il vaut mieux ne pas stocker les 2 (vous n'êtes pas en première forme normale dans ce cas...)
Pourriez-vous expliquer ce que vous voulez faire réellement? À quoi sert tout ce micmac?
Drôle d'idée.
Pourquoi ne le faites-vous pas avec 1 seul ordre SQL?
