Vous n'êtes pas identifié(e).
Pages : 1
Merci pour votre retour.
Effectivement, j'ai déjà été confronté aux raisons invoquées ...
Pour mon cas, je disais diviser environ de moitié le cost général mais sur le nœud qui m'intéresse (la lecture d'une table précise sur lequel j'ai ajouté l'index), j'ai une baisse de 63 % (de 61241 à 22401).
Je vais me permettre de penser que c'est déjà pas mal 
Bonjour,
Vous souhaitez "avoir deux colonnes calculées" mais ce n'est pas votre besoin.
Si le besoin c'est d'afficher dynamiquement (recalculer) le nom des communes liées aux colonnes inseecom_*, créer une vue avec 2 jointures vers la table communes me semble pertinent.
Bonjour,
En voulant faire baisser la durée d'une requête SELECT, j'ai ajouté un index qui n'a rien changé (ou si peu) à la durée d'exécution mais qui a (environ) divisé par 2 le cost (valeur la plus grande trouvée sur la première ligne du EXPLAIN ANALYZE).
Naivement (et à défaut d'arriver à faire baisser la durée de la requête), je me dis que pour la même durée, arriver à baisser le cost, c'est bien.
Est-ce que je me trompe ?
Comment expliquer obtenir un meilleur cost sans gain sur la durée d'exécution ?
Je me demande si par "démarrage", le LOG ne parlerait pas du "démarrage de la connexion", pas du "démarrage du serveur".
Du coup, je n'ai pas bien compris votre dernier message. Problème résolu ou pas ?
Bonjour,
Je ne m'y connais pas mais cela ressemble à ce cas là : https://forums.postgresql.fr/viewtopic.php?id=5500
Un "test de vie" (sorte de ping) qui ne ferme pas (ou mal) sa connexion.
Est-ce que cette ligne se répète dans le temps dans les logs ensuite ?
Ok, merci pour tout !
Ma lanterne vient de s'éclairer !
Hum ok
Du coup, afin de pouvoir poursuivre sur mon cas perso, qu'est-ce que "PagetableEntry" ?
Si c'est une valeur fixe à 48 qu'il ne faut pas chercher à comprendre ok (mais sinon ...)
Merci pour ce rapide retour.
Oui pardon je voulais dire 84-16 évidemment.
Effectivement, je partais mal avec mon sizeof(HASHELEMENT) (je pensais que c'était la place du type de la colonne de la table, la colonne sur laquelle se faisait le Hash ...)
Et pour le sizeof(Pointer), je n'avais dû tomber que sur des exemples 32-bit ...
Bref, je repars avec :
MAXALIGN(sizeof(HASHELEMENT)) = 16
sizeof(Pointer) = 8
Et j'arrive à :
3.2 MB = 39709 * ( MAXALIGN(sizeof(HASHELEMENT)) + MAXALIGN(sizeof(PagetableEntry)) + sizeof(Pointer) + sizeof(Pointer))
3.2 MB = 39709 * ( 16 + MAXALIGN(sizeof(PagetableEntry)) + 8 + 8)
Donc MAXALIGN(sizeof(PagetableEntry)) = 52,5008 ? disons 52 (et cela se tient : 39709*(32+52) = 39709*84 = 3335556 == 3,181034088 MB)
mais 52 ce n'est pas un multiple de 8 ... (et 48 et 56 sont trop loin)
le MAXALIGN serait bien un multiple de 8 sur un 64-bit ?
J'ai lu/relu aussi cette page : https://stackoverflow.com/questions/135 … -row-sizes
et j'ai envie de croire que je peux calculer la taille ainsi :
23 -- heaptupleheader
+ 1 -- padding or NULL bitmap
+ 4 -- 1 * integer (no alignment padding here)
+ 4 -- padding (pour arriver à un multiple de 8)
= 32
+ 0 -- no padding since tuple ends at multiple of MAXALIGN
mais je dois m'égarer car je ne suis pas à 52.
La seule chose que je remarque c'est que 52 ressemble à l'exemple : 48 (un multiple de 8) + un item pointer à 4 bytes (mais on a dit que sizeof(Pointer) == 8 )
Bref, je cale encore.
Bonjour,
Je me tire un peu les cheveux après avoir lu :
https://paquier.xyz/postgresql-2/postgr … heap-scan/
https://www.postgresql.org/message-id/0 … .ntt.co.jp
En substance, il serait question d'avoir un indice du work_mem qu'il faudrait par rapport à une requête présentant des "lossy bitmaps".
La formule donnée est :
work_mem (bytes) = (Number of lossy pages + number of exact pages) *
(MAXALIGN(sizeof(HASHELEMENT)) + MAXALIGN(sizeof(PagetableEntry))
+ sizeof(Pointer) + sizeof(Pointer))
J'ai une requête présentant des lossy bitmaps mais je n'arrive déjà pas à retrouver la valeur de 3.2 MB donnée dans l'exemple !
En supposant que :
Number of lossy pages + number of exact pages = 39709 (Heap Blocks: exact=338 lossy=39371)
MAXALIGN(sizeof(HASHELEMENT)) = 8 car MAXALIGN sur un 64-bit est à 8, et que le HASHELEMENT ici est un int4 à 4
sizeof(Pointer) = 4
j'en arrive à :
3.2 MB = 39709 * ( 16 + MAXALIGN(sizeof(PagetableEntry)) )
mais dire que MAXALIGN(sizeof(PagetableEntry)) = 84 ... je n'arrive pas à l'expliquer (je commençais à calculer le Page Header de 23+1 bytes ... )
Merci d'éclairer ma lanterne.
Ok merci.
Du coup, je me rends compte que j'ai peut-être mal posé mon besoin, pas assez élargi.
AWS RDS et GCP sont des choix clients.
L'idée est de voir jusqu'où et comment, on peut surveiller/monitorer/superviser ce genre d'instance (pour l'instant, j'étais parti sur pgbadger et temboard).
Quels autres outils de la communauté seraient pertinents sur ce genre de plateforme ?
Les outils fournis par ces plate-formes suffisent-ils ?
Ou à un moment, il faut bel et bien migrer vers une "vraie" instance Postgres que l'on maîtrise de A à Z ?
Et enfin, comment se présente le marché ?
Les clients se tournent de plus en plus vers ces plate-formes (ou pas) ?
Ils en reviennent ?
Bonjour,
Merci pour ce retour qui me confirme où j'en été arrivé.
Pour pgBadger, avez-vous un retour d'expérience ?
J'en été arrivé à KO sur GCP
et "possible mais manuel" via RDS (surtout car téléchargement manuel depuis l'interface web)
Et pour partager mes découvertes, ils parlent bien de pgbadger et donnent quand même le contournement pour le line_prefix :
https://docs.aws.amazon.com/fr_fr/Amazo … sks.Badger
Bonjour,
J'espère écrire au bon endroit (premier post).
Mon besoin : voir comment utiliser temBoard et pgBadger sur une base Postgres GoogleCloud et AWS RDS.
D'après mes recherches, pour temBoard ce n'est pas possible (sur les 2).
Je ne vois pas comment avoir la main pour installer correctement l'agent temBoard.
Quelqu'un a-t-il un REX différent là-dessus ?
Pour pgBadger :
- GoogleCloud
-- les paramètres à modifier pour pgBadger sont en grande partie modifiables (mais pas le log_line_prefix)
-- pour accéder/récupérer les fichiers logs, là par contre je sèche : j'obtiens en web un "sur-log" Google qui encapsule le log Postgres, donc inexploitable par pgBadger apparemment (et les sorties fichier possibles sont JSON et CSV).
-- donc KO pour moi. Quelqu'un a-t-il mieux que moi ?
- AWS RDS
-- les paramètres à modifier pour pgBadger sont en grande partie modifiables (log_line_prefix fixe et choix parmi 2 log_filename, à l'heure ou à la journée)
-- pas de contrôle sur le log_truncate_on_rotation mais on peut jouer avec les log_rotation_*
-- on peut consulter les logs (postgres cette fois-ci) en mode web mais peu pratique ...
-- pour récupérer les fichiers, je n'ai pas trouvé de shell (bien qu'on me donne le chemin : /rdsdbdata/log/error )
-- du coup, j'ai réussi à sortir un premier rapport pgBadger en téléchargeant manuellement 1 (à la fois) fichier de log 
-- là encore, ya plus simple/pratique/pro ?
Merci par avance pour vos retours.
Pages : 1
