postgresql
Fonctions d'agrégat
Recherche…
Statistiques simples: min (), max (), avg ()
Afin de déterminer des statistiques simples d'une valeur dans une colonne d'une table, vous pouvez utiliser une fonction d'agrégat.
Si votre table individuals
est:
prénom | Âge |
---|---|
Allie | 17 |
Amanda | 14 |
Alana | 20 |
Vous pouvez écrire cette déclaration pour obtenir la valeur minimale, maximale et moyenne:
SELECT min(age), max(age), avg(age)
FROM individuals;
Résultat:
min | max | avg |
---|---|---|
14 | 20 | 17 |
string_agg (expression, délimiteur)
Vous pouvez concaténer des chaînes séparées par un délimiteur en utilisant la fonction string_agg()
.
Si votre table individuals
est:
prénom | Âge | Pays |
---|---|---|
Allie | 15 | Etats-Unis |
Amanda | 14 | Etats-Unis |
Alana | 20 | Russie |
Vous pouvez écrire l' SELECT ... GROUP BY
pour obtenir les noms de chaque pays:
SELECT string_agg(name, ', ') AS names, country
FROM individuals
GROUP BY country;
Notez que vous devez utiliser une clause GROUP BY
car string_agg()
est une fonction d'agrégat.
Résultat:
des noms | pays |
---|---|
Allie, Amanda | Etats-Unis |
Alana | Russie |
Plus la fonction d'agrégation PostgreSQL décrite ici
regr_slope (Y, X): pente de l'équation linéaire d'ajustement par les moindres carrés déterminée par les paires (X, Y)
Pour illustrer l'utilisation de regr_slope (Y, X), je l'ai appliqué à un problème réel. En Java, si vous ne nettoyez pas correctement la mémoire, la corbeille peut rester bloquée et remplir la mémoire. Vous enregistrez des statistiques toutes les heures sur l'utilisation de la mémoire de différentes classes et les chargez dans une base de données postgres pour analyse.
Tous les candidats à la fuite de mémoire auront tendance à consommer plus de mémoire à mesure que le temps passe. Si vous tracez cette tendance, vous imaginez une ligne en haut et à gauche:
^
|
s | Legend:
i | * - data point
z | -- - trend
e |
( |
b | *
y | --
t | --
e | * -- *
s | --
) | *-- *
| -- *
| -- *
--------------------------------------->
time
Supposons que vous ayez une table contenant des données d'histogramme de vidage de tas (un mappage des classes sur la quantité de mémoire consommée):
CREATE TABLE heap_histogram (
-- when the heap histogram was taken
histwhen timestamp without time zone NOT NULL,
-- the object type bytes are referring to
-- ex: java.util.String
class character varying NOT NULL,
-- the size in bytes used by the above class
bytes integer NOT NULL
);
Pour calculer la pente de chaque classe, nous regroupons par classe. La clause HAVING> 0 garantit que nous n'obtenons que des candidats avec un slop positif (une ligne allant vers le haut et vers la gauche). Nous trions par la pente en descendant pour obtenir les classes avec le plus fort taux de mémoire en haut.
-- epoch returns seconds
SELECT class, REGR_SLOPE(bytes,extract(epoch from histwhen)) as slope
FROM public.heap_histogram
GROUP BY class
HAVING REGR_SLOPE(bytes,extract(epoch from histwhen)) > 0
ORDER BY slope DESC ;
Sortie:
class | slope
---------------------------+----------------------
java.util.ArrayList | 71.7993806279174
java.util.HashMap | 49.0324576155785
java.lang.String | 31.7770770326123
joe.schmoe.BusinessObject | 23.2036817108056
java.lang.ThreadLocal | 20.9013528767851
À la sortie, nous voyons que la consommation de mémoire de java.util.ArrayList augmente le plus rapidement à 71,799 octets par seconde et fait potentiellement partie de la fuite de mémoire.