Vous n'êtes pas identifié(e).
Bonjour tout le monde,
Je travaille sous CenOS 6.4 avec un moteur PostgreSQL 9.3.2.
Je cherche un moyen de dupliquer le contenu d'un schéma (pas les données mais la structure des tables, les vues, les fonctions, les séquences, enfin tout) dans un autre.
Tout ce que j'ai trouvé tourne autour de l'utilisation d'un dump/restore ou d'un "clone schema" sur wiki mais qui ne serait pas complet.
J'aurais voulu pouvoir le faire par une procédure stockée liée à un trigger.
Est-ce possible aujourd'hui ? Existe-t'il un "projet" complet ?
Bonjour tout le monde,
Je travaille sous CenOS 6.4 avec un moteur PostgreSQL 9.3.2.
J'utilise PgAdmin 1.18.1 depuis un PC.
Pourriez-vous me confirmer que l'on ne peut empêcher un User B de voir le contenu du schéma (description des tables) d'un User A, même s'il ne peut "rien faire avec", svp ?
Bonjour Guillaume,
Ok. Pas de warning.
Que du recyclage, une moyenne de 3 à 4 fichiers par heure.
Quelques pics d'écriture, dont un "Checkpoint Peak" de 48027 buffers (quelle est la taille d'un buffer ?), qui correspondent à un traitement journalier qui fait beaucoup d'INSERT/UPDATE.
Dans une précédente réponse, vous me disiez "Le nombre de blocs écrits par le checkpointer et le writer est plus important que le nombre de blocs écrits par les processus postgres. Ce qui est bien. Il n'empêche que le ratio est plutôt inquiétant. Ça peut être dû à l'utilisation de peu de connexions, à un cache trop petit ou à des checkpoints peu fréquents.", comment identifier la cause ? pas de warning donc les checkpoints peu fréquents sont écartés ?
Bonjour Guillaume,
J'ai relancé PgBadger comme cela :
pgbadger -p '%t [%p]: [%l-1] user= %s ' -o /home/postgres/pgbadger-5.0/test.html /home/postgres/pgbadger-5.0/LOGS/1-08.log
J'ai à présent les graphs des checkpoints, pas de warnings.
En le faisant sur plusieurs journées, je vois que les pics sont principalement sur l'export journalier et un traitement en particulier, qui s'exécute entre 5h et 6h, qui fait beaucoup de Insert/Update sur 3-4 tables.
Quelles informations vouliez-vous voir en me demandant de "Tracez les checkpoints" ?
Bonjour Guillaume,
Voici la variable log_line_prefix de mon fichier postgresql.conf :
log_line_prefix = '%t [%p]: [%l-1] user=%u %h %s '
Vous avez raison, ci-dessous 2 lignes de traces :
2014-10-27 10:02:53 CET [2613]: [33210-1] user= 2014-07-04 03:04:54 CEST LOG: checkpoint complete: wrote 1444 buffers (0.1%); 0 transaction log file(s) added, 0 removed, 1 recycled; write=144.695 s, sync=0.008 s, total=144.707 s; sync files=94, longest=0.000 s, average=0.000 s
2014-10-27 10:59:59 CET [1472]: [131358-1] user=serveurgeo 10.36.4.12 2014-10-16 00:02:13 CEST LOG: duration: 0.061 ms bind S_2: INSERT INTO geo.QUANTITE (code_cgu_site,id_perso,id_ligne,id_plan,id_fonction,id_operation,of_sec,id_document,jour,heure,nb_page,quantite,qta,qtb,qtc,qtd) values($1,$2,$3,$4,$5,$6,$7,$8,to_date($9,'yyyymmdd'),$10,$11,$12,$13,$14,$15,$16)
Sur la ligne de trace du checkpoint, il manque les %u (Utilisateur) et %h (adresse IP), mais je ne sais pas pourquoi ?
Même chose avec les analyze et vacuum (je n'ai rien dans l'onglet "vacuum" d'un html pgbadger) :
2014-10-27 18:17:20 CET [30436]: [2-1] user= 2014-10-27 18:17:19 CET LOG: automatic analyze of table "geo.geo.pointage_test" system usage: CPU 0.00s/0.47u sec elapsed 0.53 sec
J'ai l'impression que je n'ai pas les infos sur les traces générées par le serveur lui-même.
Bonjour Guillaume,
Ci-dessous les paramètres du postgresql.conf :
max_connections = 300
shared_buffers = 8192MB
work_mem = 10MB
maintenance_work_mem = 4096MB
checkpoint_segments = 64
checkpoint_timeout = 10min
effective_cache_size = 21840MB
32Go de RAM sur la machine.
En moyenne, 130 à 140 utilisateurs connectés.
Le log_checkpoints est bien à ON, j'ai bien des logs du style :
2014-10-27 08:10:28 CET [2613]: [33187-1] user= 2014-07-04 03:04:54 CEST LOG: checkpoint starting: time
2014-10-27 08:11:16 CET [2613]: [33188-1] user= 2014-07-04 03:04:54 CEST LOG: checkpoint complete: wrote 476 buffers (0.0%); 0 transaction log file(s) added, 0 removed, 0 recycled; write=47.524 s, sync=0.009 s, total=47.536 s; sync files=113, longest=0.000 s, average=0.000 s
2014-10-27 08:20:28 CET [2613]: [33189-1] user= 2014-07-04 03:04:54 CEST LOG: checkpoint starting: time
2014-10-27 08:21:38 CET [2613]: [33190-1] user= 2014-07-04 03:04:54 CEST LOG: checkpoint complete: wrote 696 buffers (0.1%); 0 transaction log file(s) added, 0 removed, 0 recycled; write=69.572 s, sync=0.011 s, total=69.587 s; sync files=72, longest=0.001 s, average=0.000 s
2014-10-27 08:30:28 CET [2613]: [33191-1] user= 2014-07-04 03:04:54 CEST LOG: checkpoint starting: time
2014-10-27 08:31:37 CET [2613]: [33192-1] user= 2014-07-04 03:04:54 CEST LOG: checkpoint complete: wrote 690 buffers (0.1%); 0 transaction log file(s) added, 0 removed, 1 recycled; write=69.071 s, sync=0.008 s, total=69.082 s; sync files=83, longest=0.000 s, average=0.000 s
2014-10-27 08:40:28 CET [2613]: [33193-1] user= 2014-07-04 03:04:54 CEST LOG: checkpoint starting: time
2014-10-27 08:42:12 CET [2613]: [33194-1] user= 2014-07-04 03:04:54 CEST LOG: checkpoint complete: wrote 1041 buffers (0.1%); 0 transaction log file(s) added, 0 removed, 0 recycled; write=104.147 s, sync=0.009 s, total=104.158 s; sync files=95, longest=0.000 s, average=0.000 s
Par contre, je n'ai rien dans "l'onglet" Checkpoints, d'une sortie HTML de PgBadger 5, exécuté de la façon suivante :
pgbadger -p '%t [%p]: [%l-1] user=%u %h %s ' -u postgres -o /home/postgres/pgbadger-5.0/HTML/postgres_20141027.html /home/postgres/pgbadger-5.0/LOGS/3-*.log
Bonjour Guillaume,
C'est vrai qu'il manque quelques infos, désolé.
Alors, j'ai repris la technique suivante, extraite du livre "Base de données PostgreSQL - Gestion des performances", Chapitre 11 "Activité et statistiques de la base de données", paragraphe "Sauvegarder des images de pg_stat_bgwriter" :
Toutes les 6 heures, je fais la "photo" : INSERT INTO pg_stat_bgwriter_snapshot (SELECT current_timestamp,* FROM pg_stat_bgwriter);
Ensuite, le dimanche, je fais la requête suivante pour extraire les infos de ma table de collecte :
select cast(date_trunc('second',now) as timestamp) as jour,
date_trunc('second',elapsed) as elapsed,
date_trunc('second',elapsed/(checkpoints_timed+checkpoints_req)) as avg_checkpoint_interval,
(100 * checkpoints_req) / (checkpoints_timed + checkpoints_req) AS checkpoint_requis,
100 * buffers_checkpoint / (buffers_checkpoint + buffers_clean + buffers_backend) AS checkpoint_serveur,
100 * buffers_backend / (buffers_checkpoint + buffers_clean + buffers_backend) AS checkpoint_client,
pg_size_pretty(buffers_checkpoint * block_size / (checkpoints_timed + checkpoints_req)) AS volume_moyen_ecrit,
pg_size_pretty(cast(block_size * (buffers_checkpoint + buffers_clean + buffers_backend) / extract(epoch FROM elapsed) AS int8)) AS volume_ecrit,
pg_size_pretty(cast(block_size * (buffers_alloc) / extract(epoch FROM elapsed) AS int8)) AS volume_lecture
from
(select now,
((lead(now,1) over(order by now))-now) as elapsed,
((lead(checkpoints_timed,1) over(order by now))-checkpoints_timed) as checkpoints_timed,
((lead(checkpoints_req,1) over(order by now))-checkpoints_req) as checkpoints_req,
((lead(buffers_checkpoint,1) over(order by now))-buffers_checkpoint) as buffers_checkpoint,
((lead(buffers_clean,1) over(order by now))-buffers_clean) as buffers_clean,
((lead(maxwritten_clean,1) over(order by now))-maxwritten_clean) as maxwritten_clean,
((lead(buffers_backend,1) over(order by now))-buffers_backend) as buffers_backend,
((lead(buffers_alloc,1) over(order by now))-buffers_alloc) as buffers_alloc,
(select cast(current_setting('block_size') as integer)) as block_size
from pg_stat_bgwriter_snapshot
order by now) as bgwriter_diff
where (checkpoints_timed+checkpoints_req)>0;
Les buffers_checkpoint sont donc bien en majorité supérieur aux buffers_backend, cependant ces derniers augmentent.
Dans quelle mesure faut-il s'en inquiéter ?
Concernant le cache, oui c'est bien le cache Linux qui est à 24Go.
Merci encore pour votre analyse.
Bonjour Guillaume,
Désolé pour ma question un peu inadaptée.
En fait nous avions plusieurs bases de données (une par site) et nous avons évolué vers une architecture centralisée (une seule machine plus puissante, plus de mémoire, disques plus gros, OS mieux utilisé, séparation des data et logs sur différents disques, ...) et nous rapatrions progressivement les données et traitements des différents sites.
J'essaye de mettre en place les outils qui me permettront d'anticiper d'éventuels problèmes.
J'ai des infos au niveau système grâce à une surveillance Centreon.
Le ratio Cache hit/miss de ma BD reste au-dessus de 96%.
Le volume des données est bien géré.
J'ai mis en place la prise de "photos" de la table pg_stat_bgwriter, mais j'ai du mal à en interpréter les résultats.
Je me demande si les "Checkpoints clients" ne sont pas trop nombreux ?
Le volume des écritures a augmenté, je pense, avec l'augmentation de l'activité de la base.
Le volume des lectures a lui augmenté de façon plus significative.
Est-ce à dire que toutes les infos ne tiennent plus en mémoire ?
La machine dispose de 32Go et le cache n'est qu'à 24Go.
Le ratio global ne devrait-il pas baisser ?
Plus globalement, sur quels critères dois-je me baser pour lever une alerte ?
Bonjour,
Je prend également des photos de la table pg_stat_bgwriter, toutes les 6h, du lundi au samedi :
Checkpoint requis Checkpoint Serveur Checkpoint Client Volume moyen écrit (kB/Check) Volume écriture (kB/s) Volume lecture (kB/s)
0h 6h 12h 18h 0h 6h 12h 18h 0h 6h 12h 18h 0h 6h 12h 18h 0h 6h 12h 18h 0h 6h 12h 18h
20140526 0 0 0 0 71 66 70 53 28 33 29 46 0718 4403 4145 1176 01,721 11,000 10,068 03,751 07,143 002,880 019,000 00,381
20140527 0 0 0 0 78 68 70 52 21 31 29 47 2752 6096 4205 1130 05,992 15,000 10,179 03,663 01,653 003,997 016,000 00,440
20140528 0 0 0 0 77 68 65 47 22 31 34 52 2775 4375 3273 0937 06,144 11,000 08,498 03,386 01,342 007,080 000,650 00,404
20140529 0 0 0 0 76 49 43 45 23 50 56 54 2209 1373 1076 0845 04,910 04,704 04,212 03,174 00,938 000,083 000,076 00,055
20140530 0 0 0 0 92 62 61 48 07 37 38 51 0666 2925 2659 0998 01,228 07,981 07,428 03,493 00,135 000,845 000,518 00,459
20140531 0 0 0 0 76 57 46 00 23 42 53 00 1824 1958 1232 0000 04,073 05,876 04,559 00,000 00,784 000,226 000,166 00,000
Checkpoint requis Checkpoint Serveur Checkpoint Client Volume moyen écrit (kB/Check) Volume écriture (kB/s) Volume lecture (kB/s)
0h 6h 12h 18h 0h 6h 12h 18h 0h 6h 12h 18h 0h 6h 12h 18h 0h 6h 12h 18h 0h 6h 12h 18h
20141027 0 0 0 0 76 59 58 38 23 40 41 61 1250 6760 5603 1497 02,778 19,000 16,000 06,627 09,109 190,000 051,000 00,558
20141028 0 0 0 0 74 62 61 38 25 37 38 61 4872 8120 5973 1541 11,000 22,000 16,000 06,778 03,704 005,870 284,000 01,836
20141029 0 0 0 0 80 59 61 35 19 40 38 64 5711 6088 7803 1284 12,000 17,000 21,000 06,255 64,000 025,000 407,000 02,927
20141030 0 0 0 0 82 61 59 46 16 38 40 53 6221 6474 6379 2781 12,000 18,000 18,000 10,227 75,000 325,000 885,000 33,000
20141031 0 0 0 0 76 60 61 47 23 39 37 52 3946 6435 6621 2502 08,785 18,000 18,000 08,993 69,000 584,000 675,000 04,796
20141101 0 0 0 0 80 75 28 33 19 24 71 66 4374 8990 1140 0991 09,319 20,000 06,798 05,060 83,000 000,810 000,177 00,109
Je vois une augmentation du volume des écritures, mais surtout des lectures.
En même temps, comme il s'agit d'une base "centrale", dans laquelle de nouveaux sites sont venus s'intégrer (donc le nombre des connexions a augmenté, le volume des traitements et le volume des tables également) et que nous n'avons pas de remonté d'informations sur des lenteurs ou blocages, je ne suis pas trop inquiet.
Les volumes de lecture/écriture sont ils cohérents ?
Bonjour Anayrat,
Au niveau système, c'est bon, j'ai des graph centreon avec les lectures/écritures sur les différents disques (OS+moteur+logs sur disque A, data sur disque B, journaux sur disque C).
Je surveille déjà :
Taille BD : SELECT pg_database_size('ma_base');
Taille Table + Indexes + autres Relations rattachés : SELECT pg_total_relation_size('ma_table');
Le ratio cache hit/miss sur la BD (lecture en cache si bien compris) : SELECT ROUND((blks_hit::FLOAT/(blks_read+blks_hit+1)*100)::NUMERIC,2) FROM pg_stat_database WHERE datname='ma_base';
Je voudrai également surveiller les lectures/écritures côté base de données. Si j'ai bien compris : l'écriture des journaux de transactions, l'écriture en base et l'écriture des logs.
Merci pour votre aide.
Bonjour tout le monde,
Je travaille sous CenOS 6.4 avec un moteur PostgreSQL 9.3.2.
J'ai accès à des graphs centreon de surveillance des I/O sur mon serveur, mais je cherche le moyen de calculer le ratio des lectures/écritures de ma base de données.
Quelqu'un peut-il aiguiller mes recherches, svp ?
D'avance merci.
Bonjour Guillaume,
C'est ce que j'avais fait en attendant, je pensais qu'il y avait "plus propre".
Merci.
Bonjour tout le monde,
Je travaille sous CenOS 5.4 avec un moteur PostgreSQL 9.3.2.
Je souhaite écrire une procédure stockée dans laquelle je veux fixer le TIMEZONE à l'aide d'une variable (cTimeZone).
Ci-dessous un bout de mon code :
......
cTimeZone VARCHAR(50);
BEGIN
SELECT timezone INTO cTimeZone FROM TOTO.Site WHERE id_cgu=$1 AND id_site=$2;
IF cTimeZone IS NOT NULL AND cTimeZone!='' THEN SET TIME ZONE cTimeZone;END IF;
.....
Cela ne fonctionne pas, à l'exécution de ma procédure j'obtiens :
ERROR: invalid value for parameter "TimeZone": "ctimezone"
CONTEXT: SQL statement "SET TIME ZONE cTimeZone"
PL/pgSQL function poin(character varying,character varying,character varying,character varying,character,character) line 20 at SQL statement
********** Erreur **********
ERROR: invalid value for parameter "TimeZone": "ctimezone"
État SQL :22023
Contexte : SQL statement "SET TIME ZONE cTimeZone"
PL/pgSQL function poin(character varying,character varying,character varying,character varying,character,character) line 20 at SQL statement
Comment faire interpréter mon "cTimeZone" dans la commande SET TIME ZONE ?
Bonjour Thomas,
Je me permets d'intervenir car en lisant votre post, je vois que le champ défini dans la table est "datemaj" alors que dans votre requête c'est "datmaj" (manque le e).
Bonjour Guillaume,
Bon d'accord, je ne vais pas réinitialiser les stats et regarder cet outil.
Merci encore.
Bonjour Guillaume,
Donc pas une bonne idée de réinitialiser les statistiques le dimanche. Sinon, les tables pour lesquelles il y aurait des modifications (Insert/update/Delete) pourraient ne jamais être vacuumé ?
Mais dans ce cas, comment avoir des statistiques "parlantes", par exemple à la semaine (nombre de transactions, nombre d'insert/update/delete, parcours séquentiels ou parcours d'index, ......) ?
Rebonjour,
Désolé, j'avais mis le post en [résolu] un peu vite.
Le PG_STAT_RESET va remettre les compteurs à zéro, par exemple dans la table PG_STAT_USER_TABLES. Le VACUUM ne se base t'il pas sur les compteurs n_live_tup et n_dead_tup pour ses déclenchements ?
Le PG_STAT_RESET réinitialise t'il également les compteurs du BGWRITER ?
Bonjour Guillaume,
Ok, merci encore pour votre aide.
Ok, merci Guillaume pour l'analyse.
Comme il n'y a pas de grosse activité, je pense faire des snapshots toutes les 6 heures.
Pour que les compteurs soient un peu plus parlant, je voudrais faire un reset des compteurs le dimanche, pour avoir des chiffres à la semaine.
Le PG_STAT_RESET() peut-il avoir des effets négatifs sur l'optimiseur de requêtes ou autre ?
Est-ce une bonne pratique ?
Bonjour Guillaume,
La surveillance de pg_stat_bgwriter porte sur 1h30, entre 10h10 et 11h30, avec une photo toutes les dix minutes.
Pouvez-vous vérifier cela, svp ?
Pour les sum_read et sum_hit, ils sont le résultat de :
Création de la table : CREATE TABLE pg_stat_database_snapshot AS SELECT current_timestamp,blks_read,blks_hit FROM pg_stat_database where datname='geo';
Prise d'une photo toutes les 10 minutes.
Résultat de la requête :
select round((((lead(blks_read,1) over(order by now))-blks_read)*8192)/1024/1024,2) as read_Mo,round((((lead(blks_hit,1) over(order by now))-blks_hit)*8192)/1024/1024,2) as cache_Mo
from pg_stat_database_snapshot;
Merci pour votre analyse.
Bonjour Guillaume,
Merci pour les fonctions de fenêtrage (un nouvel outil bien sympa).
J'ai donc modifier ma requête :
select cast(date_trunc('second',now) as timestamp) as jour,
date_trunc('second',elapsed) as elapsed,
date_trunc('second',elapsed/(checkpoints_timed+checkpoints_req)) as avg_checkpoint_interval,
(100 * checkpoints_req) / (checkpoints_timed + checkpoints_req) AS checkpoints_req_pct,
100 * buffers_checkpoint / (buffers_checkpoint + buffers_clean + buffers_backend) AS checkpoint_write_pct,
100 * buffers_backend / (buffers_checkpoint + buffers_clean + buffers_backend) AS backend_write_pct,
pg_size_pretty(buffers_checkpoint * block_size / (checkpoints_timed + checkpoints_req)) AS avg_checkpoint_write,
pg_size_pretty(cast(block_size * (buffers_checkpoint + buffers_clean + buffers_backend) / extract(epoch FROM elapsed) AS int8)) AS written_per_sec,
pg_size_pretty(cast(block_size * (buffers_alloc) / extract(epoch FROM elapsed) AS int8)) AS alloc_per_sec
from
(select now,
((lead(now,1) over(order by now))-now) as elapsed,
((lead(checkpoints_timed,1) over(order by now))-checkpoints_timed) as checkpoints_timed,
((lead(checkpoints_req,1) over(order by now))-checkpoints_req) as checkpoints_req,
((lead(buffers_checkpoint,1) over(order by now))-buffers_checkpoint) as buffers_checkpoint,
((lead(buffers_clean,1) over(order by now))-buffers_clean) as buffers_clean,
((lead(maxwritten_clean,1) over(order by now))-maxwritten_clean) as maxwritten_clean,
((lead(buffers_backend,1) over(order by now))-buffers_backend) as buffers_backend,
((lead(buffers_alloc,1) over(order by now))-buffers_alloc) as buffers_alloc,
(select cast(current_setting('block_size') as integer)) as block_size
from pg_stat_bgwriter_snapshot
order by now) as bgwriter_diff
where (checkpoints_timed+checkpoints_req)>0;
J'obtiens les résultats suivants pour les 2 dernières heures :
jour elapsed avg_checkpoint_interval checkpoints_req_pct checkpoint_write_pct backend_write_pct avg_checkpoint_write written_per_sec alloc_per_sec
2014-05-15 10:10:01 00:10:00 00:10:00 0 60 39 3472 kB 9829 bytes 2212 bytes
2014-05-15 10:20:01 00:10:00 00:10:00 0 65 34 6416 kB 16 kB 3618 bytes
2014-05-15 10:30:01 00:10:00 00:10:00 0 73 26 8424 kB 19 kB 2252 bytes
2014-05-15 10:40:01 00:10:00 00:10:00 0 67 32 5400 kB 13 kB 942 bytes
2014-05-15 10:50:01 00:10:00 00:10:00 0 59 40 3880 kB 11 kB 778 bytes
2014-05-15 11:00:02 00:09:59 00:09:59 0 93 6 3792 kB 6946 bytes 711 bytes
2014-05-15 11:10:01 00:10:00 00:10:00 0 61 38 3808 kB 10 kB 505 bytes
2014-05-15 11:20:01 00:10:00 00:10:00 0 77 22 4032 kB 8873 bytes 614 bytes
2014-05-15 11:30:01 00:10:00 00:10:00 0 65 34 3408 kB 8914 bytes 491 bytes
J'ai également fait cette requête pour avoir le ratio de lecture en cache :
select round((((lead(sum_read,1) over(order by now))-sum_read)*8192)/1024/1024,2) as read_Mo,round((((lead(sum_hit,1) over(order by now))-sum_hit)*8192)/1024/1024,2) as cache_Mo
from pg_stat_database_snapshot
where datname='geo'
and to_char(now,'YYYYMMDD')='20140515' and to_char(now,'HH24:MI:SS')>'100000';
J'obtiens les chiffres suivants :
read_mo cache_mo
0.39 5410.89
0.51 14342.68
2.83 22846.39
1.29 13710.18
0.54 7395.71
0.45 8036.46
0.40 12417.09
0.30 7482.95
0.35 13399.13
0.28 6752.86
Les paramètres de mon postgresql.conf sont :
max_connections = 300
shared_buffers = 8192MB
work_mem = 10MB
maintenance_work_mem = 4096MB
checkpoint_segments = 64
checkpoint_timeout = 10min
effective_cache_size = 21840MB
Pouvez-vous me donner votre avis sur le comportement de ma base, svp ?
Encore merci pour votre aide.
Bonjour Guillaume,
J'ai repris la technique suivante, extraite du livre "Base de données PostgreSQL - Gestion des performances", Chapitre 11 "Activité et statistiques de la base de données", paragraphe "Sauvegarder des images de pg_stat_bgwriter" :
Création d'une table : CREATE TABLE pg_stat_bgwriter_snapshot AS SELECT current_timestamp,* FROM pg_stat_bgwriter;
Insertion d'une image dans la table par crontab toutes les 5 minutes : INSERT INTO pg_stat_bgwriter_snapshot (SELECT current_timestamp,* FROM pg_stat_bgwriter);
J'essaye d'utiliser la requête suivante qui exploite les informations de la table :
SELECT
cast(date_trunc(‘minute’,start) AS timestamp) AS start,
date_trunc(‘second’,elapsed) AS elapsed,
date_trunc(‘second’,elapsed / (checkpoints_timed + checkpoints_req)) AS avg_checkpoint_interval,
(100 * checkpoints_req) / (checkpoints_timed + checkpoints_req) AS checkpoints_req_pct,
100 * buffers_checkpoint / (buffers_checkpoint + buffers_clean + buffers_backend) AS checkpoint_write_pct,
100 * buffers_backend / (buffers_checkpoint + buffers_clean + buffers_backend) AS backend_write_pct,
pg_size_pretty(buffers_checkpoint * block_size / (checkpoints_timed + checkpoints_req)) AS avg_checkpoint_write,
pg_size_pretty(cast(block_size * (buffers_checkpoint + buffers_clean + buffers_backend) / extract(epoch FROM elapsed) AS int8)) AS written_per_sec,
pg_size_pretty(cast(block_size * (buffers_alloc) / extract(epoch FROM elapsed) AS int8)) AS alloc_per_sec
FROM
(
SELECT
one.now AS start,
two.now - one.now AS elapsed,
two.checkpoints_timed - one.checkpoints_timed AS checkpoints_timed,
two.checkpoints_req - one.checkpoints_req AS checkpoints_req,
two.buffers_checkpoint - one.buffers_checkpoint AS buffers_checkpoint,
two.buffers_clean - one.buffers_clean AS buffers_clean,
two.maxwritten_clean - one.maxwritten_clean AS maxwritten_clean,
two.buffers_backend - one.buffers_backend AS buffers_backend,
two.buffers_alloc - one.buffers_alloc AS buffers_alloc,
(SELECT cast(current_setting(‘block_size’) AS integer)) AS block_size
FROM pg_stat_bgwriter_snapshot one
INNER JOIN pg_stat_bgwriter_snapshot two ON two.now > one.now
) bgwriter_diff
WHERE (checkpoints_timed + checkpoints_req) > 0;
Je n'arrive pas à l'adapter pour qu'elle traite l'ensemble des enregistrements de la table et non pas uniquement deux enregistrements.
En fait chaque ligne est comparée avec L'ENSEMBLE des suivantes et non pas uniquement avec LA suivante.
Pourriez-vous m'apporter votre aide ?
D'avance merci.
C'est vrai, je suis bête :-(
Merci Arthurr.
Bonjour Arthurr,
Merci pour la réponse, cela fonctionne bien.
J'ai une petite question subsidiaire : je dois ajouter d'autres colonnes dans ma table avec des valeurs numériques, sur lesquelles je souhaite faire des calculs du style addition, soustraction et division.
CREATE TABLE ma_table (
now timestamp with time zone,
action character varying(3),
nb1_action integer,
nb2_action integer);
Nouveau contenu de ma table :
"2014-05-13 10:57:14.209095+02";"01";0;0
"2014-05-13 10:59:47.221529+02";"02";0;0
"2014-05-13 11:00:28.773153+02";"03";1;3
"2014-05-13 11:05:25.814538+02";"04";4;2
La requête suivante :
Select a.action,
a.now,
date_trunc('second',((lead(a.now,1) over(order by a.now))-a.now)) as temps,
date_trunc('second',((lead(now,1) over(order by now))-now)/(((lead(nb1_action,1) over(order by now))-nb1_action)+((lead(nb2_action,1) over(order by now))-nb2_action))) AS calcul
from ma_table a
order by a.now;
Me retourne le message d'erreur "division by zero".
Comment faire pour tester que le diviseur de mon calcul est supérieur à zéro ?
Encore merci pour votre aide.
Bonjour tout le monde,
Je travaille sous CenOS 5.4 avec un moteur PostgreSQL 9.3.2.
J'ai une table dans laquelle je stocke des actions et le moment où cette action est faite (current_timestamp) :
CREATE TABLE ma_table(
now timestamp with time zone,
action character varying(3));
Contenu de ma table :
"2014-05-13 10:57:14.209095+02";"01"
"2014-05-13 10:59:47.221529+02";"02"
"2014-05-13 11:00:28.773153+02";"03"
"2014-05-13 11:05:25.814538+02";"04"
Je voudrai afficher le temps passé entre 2 actions en utilisant une auto-jointure :
SELECT A.now AS Debut,B.now-A.now AS Temps,A.action
FROM ma_table A INNER JOIN ma_table B ON B.now>A.now
ORDER BY A.now;
Le résultat n'est pas celui attendu :
"2014-05-13 10:57:14.209095+02";"00:02:33.012434";"01"
"2014-05-13 10:57:14.209095+02";"00:03:14.564058";"01"
"2014-05-13 10:57:14.209095+02";"00:08:11.605443";"01"
"2014-05-13 10:59:47.221529+02";"00:00:41.551624";"02"
"2014-05-13 10:59:47.221529+02";"00:05:38.593009";"02"
"2014-05-13 11:00:28.773153+02";"00:04:57.041385";"03"
Quelqu'un a t'il une idée ? pour ne traiter qu'une fois chaque ligne ?
D'avance merci pour votre aide.
