Vous n'êtes pas identifié(e).
test=# select materiaux, count(*) as total, count(*) / (sum(count(*)) over())*100 as pourcentage from matable group by materiaux;
materiaux | total | pourcentage
-----------+-------+-------------------------
fonte | 5 | 62.50000000000000000000
pvc | 3 | 37.50000000000000000000
(2 rows)bonjour,
http://docs.postgresql.fr/9.3/runtime-c … gging.html
vous pouvez paramétrer postgresql avec log_statement = 'all' + log_connection = on (attention aux perfs !).
vous devez modifier également log_line_prefix pour avoir les infos que vous voulez (IP, date, base, utilisateur ...)
il est églament possible de logger au format csv : chapitre 18.8.4. "Utiliser les journaux au format CSV"
Ainsi lorsque l'utilisateur veut utiliser son application, il n'a plus à préciser l'hôte, son numéro de port ou autre information, tout ce qu'il aura à faire c'est entre le login et son mot de passe.
hote + port + user + pwd => postgresql n'en demande pas plus
je confirme ce que dit pitpoule, mes standby en hot-streaming génèrent des WAL dans pg_xlog avec la même numérotation que le master et à la même vitesse (je ne parle pas de l'archivage du master vers le slave fait via archive_command).
et la dépêche sur LinuxFR :
http://linuxfr.org/news/postgresql-9-3
Pas d'annonce officielle encore, mais les sources sont disponibles : http://www.postgresql.org/ftp/source/v9.3.0/
je viens de faire des tests, et j'ai le même problème sur une 9.2.4
De ce que je comprend, c'est basé sur strftime qui se base sur la locale du système (ou du fichier de conf pour le coup).
je n'avais jamais utilisé le %a, je travaille avec %d (30/31 fichiers de logs pour conserver un mois).
Au pire (même si ce n'est pas très satisfaisant), vous pouvez utiliser %w (0 = dimanche) en attendant que quelqu'un vous apporte la solution (ou pas) 
lc_time est bien positionné à "fr_FR.UTF-8" dans postgresql.conf ?
Et dans l'idéal : utilisez un "PREPARE" puis "EXECUTE" avec le passage des paramètres dans le "EXECUTE" : http://docs.postgresql.fr/9.1/sql-prepare.html
La majorité des langages proposent cette possibilité
pour moi il y a un pbs de conception, mais peut être que je ne comprends pas assez bien ton problème ...
J’aurai fait 3 tables :
- operation_reseau(operation_reseau_id(PK), ...)
- geo(geo_id(PK), type_geo_id(FK), operation_reseau_id(FK), ...)
- type_geo(type_geo_id(PK), num_geo, ...)
avec dans la colonne num_geo de la table type_geo les X des tables geo_X (1,2,3,4, ...)
C'est à mon avis bcp plus simple par la suite pour faire tes comptages.
Concernant tes contraintes (un operation_reseau_id pour un seul type_geo_id, mais avec N lignes possibles) -> vérification à faire par trigger BEFORE INSERT, UPDATE
si tu as 0 c'est que tous les champs dates correspondent à autre chose que '1970-01...' (une date ou un valeur NULL si elle est acceptée)
et tu sais par quelle valeur tu vas remplacer '1970-01...' pour chaque colonne de chaque table ?
tu peux déjà lancer cette requête qui va te sortir une liste de select à effectuer pour savoir si tu as des données à 1970-01-01 pour tes colonne de type TIMESTAMP WITHOUT TIME ZONE :
select 'select count(*) from ' || table_schema || '.' || table_name || ' where ' || column_name || '=''1970-01-01 00:00:00'';' from INFORMATION_SCHEMA.COLUMNS where data_type='timestamp without time zone';Bonjour,
le DATETIME de Mysql est équivalent au TIMESTAMP de PostgreSQL.
Le vrais problème est que la colonne était NOT NULL et que Mysql remplace une valeur NULL par '0000-00-00 00:00:00'
Le plus simple => passer la colonne en NULLABLE et updater toutes les valeurs '1970-01-01 00:00:00' à NULL
Si la colonne ne doit vraiment pas être NULL, je ne vois pas quelle valeur vous allez mettre dans le cas '0000-00-00 00:00:00' / '1970-01-01 00:00:00'
le 1/ en utilisant une fonction automatique d’échappement suivant le langage utilisé pour peupler la base (quote en perl, pg_escape_bytea en php, ...).
"Le volume final est de ce fait augmenté d'un facteur 2 à 3" : d'après la doc, non : "Par exemple, une chaîne littérale passée au serveur comme E'\\001' devient \001 après être passée au travers de l'analyseur d'échappement de chaîne. Le \001 est envoyé à la fonction d'entrée de bytea, qui le convertit en un octet simple ayant une valeur décimale de 1", de plus ta donnée va être "Toasted" donc compressée.
Si vous n'avez pas à faire de requêtes sur ces données binaires, autant ne pas les stocker dans la base.
Habituellement (enfin pour moi), on stock le PATH du fichier binaire dans la base et ce PATH pointe vers un fichier sur le FileSystem.
La base est plus petite, donc plus facile à sauvegarder / restaurer, par contre, il faut penser à backuper les fichiers sur le FS.
bonjour,
pourquoi ne pas executer le script avec le user Postgres ?
Ce monsieur passe son temps à écrire ce genre d'articles TRÈS TRÈS orientés.
Et à la moindre critique il annonce que les gens de la communauté ne supportent pas la moindre critique.
Faut juste laisser passer : un jour il va se fatiguer (ou pas).
Bonjour,
Cohérence : oui sans problème pour les deux.
pg_dump => backup d'une base d'un cluster
pg_dumpall => backup de toutes les bases d'un cluster
Pas de magie en termes de performances mais avec 10000 lignes ça doit passer sans trop de problème :
postgres=# create table titi(toto integer);
CREATE TABLE
postgres=# insert into titi values(1);
INSERT 0 1
postgres=# insert into titi values(2);
INSERT 0 1
postgres=# insert into titi values(5);
INSERT 0 1
postgres=# select foo.val from (select generate_series(1,10000) as val) as foo where not exists (select 1 from titi where foo.val = titi.toto) limit 1;
val
-----
3
(1 row)vous pouvez vous connecter en plsql et faire "show all;" sur chaque base pour voir si il y a une différence de configuration.
(le track_counts peut être modifié pour une base du cluster par exemple : alter database ??? set track_counts to 'off')
que donne :
show track_counts;sur la base qui pose problème ?
Bonjour,
J'utilise cette requête :
select
current_database(),
schemaname || '.' || relname as table,
to_char(last_vacuum,'DD-MM-YYYY HH24:mi') as lastvacuum,
to_char(last_autovacuum,'DD-MM-YYYY HH24:mi') as lastautovacuum,
to_char(last_analyze,'DD-MM-YYYY HH24:mi') as lastanalyze,
to_char(last_autoanalyze,'DD-MM-YYYY HH24:mi') as lastautoanalyze
from
pg_stat_user_tables
order by
2Vous n'aurez pas l'historique du déclenchement de l'autovacuum mais au moins la date du dernier lancement par table
Il est assez difficile de conseiller qq'un sur une configuration sans connaitre exactement l'utilisation de la base.
Comme le dit gleu, il existe un grand nombre d'articles => http://wiki.postgresql.org/wiki/Perform … timization
Quelques petits idées :
1/ Je vous conseille de passer le shared_buffer à 1Go (vu la taille de votre base, elle va tenir en totalité en RAM).
Vous allez surement devoir modifier la variable shmmax de votre kernel : http://docs.postgresqlfr.org/9.1/kernel-resources.html
2/ Vous devriez probablement modifier le work_mem de postgresql mais attention au nombre de connexions simultanées.
3/ modifier synchronous_commit = off
4/ modifier random_page_cost = 3 (ou 2 : à tester)
Pas de magie sans tests et sans une connaissance précise de l'utilisation
Bonjour,
quelle version de PostgreSql ?
quelle valeur pour shared_buffers (postgresql.conf) ?
quelle quantité de ram sur votre serveur ?
quelle est la taille de votre base ?
le serveur est-il dédié à PostgreSql ?
des ralentissements en lecture (select) ou en écriture (insert / update) ?
Bonjour,
Nombre de fois où la requête a été exécutée