Bonjour,

Le format de nommage de ces fichiers ressemble plutôt à ce que produit la commande "mktemp", pas à ce que produirait postgresql. Vous avez probablement un script quelque part qui crée ces répertoires.

Bonjour,
Aucune idée, Azure Database for PostgreSQL est un service propriétaire de Microsoft. Pourquoi ne vous adressez-vous pas à eux ?

L'explication la plus simple que je vois: vous avez déclaré le trigger comme "AFTER". Si ce n'était pas le cas vous auriez des erreurs sur les INSERT. Par contre, pour pouvoir modifier NEW, il faut un trigger BEFORE. Donc je pense que vu ce que vous voulez faire, c'est un trigger BEFORE qui modifie NEW, et un trigger AFTER qui fait les insert.

=> Vous avez des champs trop gros pour être indexés. J'imagine que c'est une chaîne de caractères que vous essayez d'indexer ? Si oui, il y a une limite (elle est même plus basse en fait). On a quelques moyens de contournement, mais c'est à voir dans un second temps.

Non, pas forcément, on peut très bien avoir des retours de chariots dans un CSV. Un enregistrement de ce genre par exemple:

1;"bonjour
les copains"
2;toto

3 lignes, 2 enregistrements.

C'est voulu dans le code. to_timestamp essaye de son mieux, sans faire d'erreur, même si la chaîne ne format est "mauvaise". Ici, Les nombres dans la chaîne de formatage sont simplement ignorés. Je ne suis pas fan non plus, mais c'est comme ça, et voulu...

Bonjour,

Une fonction d'agregation, c'est pas vraiment ce qui se fait de plus simple pour commencer, mais bon, essayons quand même...

Ce qu'on dit avec le create aggregate, c'est que pour calculer cet agrégat, on a une variable d'état qui est un tableau de numeric, qu'à chaque nouvel élément on l'ajoute à la fin du tableau (array_append), et qu'une fois qu'on a vu tous les enregistrements de l'agrégat, on appelle _final_median pour retourner la valeur de l'agrégat. initcond permet d'initialiser la variable d'état à un tableau vide.

La fonction est une fonction SQL (donc une simple requête). La valeur de retour de la fonction est donc le résultat de la requête. Les paramètres sont numérotés $1, $2, etc… (on peut leur donner des noms, mais là, vu qu'il n'y en a qu'un…)

Comme $1 est un tableau, on l'unnest (pour en refaire une liste d'enregistrements). On trie par la sortie de l'unnest (logique), et on récupère soit un soit deux enregistrements (suivant la valeur du modulo 2 de array_upper($1,1), c'est à dire la taille du tableau). Donc si le tableau a un nombre impair d'enregistrements, on prend 1 enregistrements, si il a un nombre pair, on en prend deux (pour calculer la moyenne). Même idée pour l'offset, on prend le ceil(milieu du tableau). Donc ce subselect nous retourne le ou les deux enregistrements du «milieu». La requête principale en retourne la moyenne.

Maintenant que tout ça est posé, pourquoi on comptabilise les null? Parce qu'ils sont dans le tableau. Donc pour éviter ça, deux solutions (désolé je vais dire des évidences ):
- ne pas les avoir dans le tableau
- les ignorer à la fin

Pour ne pas les avoir dans le tableau, il faut utiliser une fonction "stricte" d'état, c'est à dire une fonction déclarée comme stricte (c'est un des arguments de create function). C'est à dire une fonction qui retourne NULL quand on lui passe NULL. Évidemment, array_append n'est pas stricte. On peut par exemple pour se sortir de votre problème déclarer une fonction stricte qui fait comme array_append, mais déclarée stricte. Quelque chose comme (je n'ai pas testé):

CREATE  OR REPLACE FUNCTION _strict_array_append(ANYARRAY, ANYELEMENT) RETURNS ANYARRAY STRICT AS 
$$
  SELECT array_append($1,$1)
$$

(array_append est polymorphique, autant faire pareil)

Qu'il suffira d'utiliser dans l'agrégat à la place de l'autre.

Sinon, l'autre solution, c'est juste d'ignorer les NULL dans la fonction finale (moins bon d'un point de vue algorithmique évidemment, mais peut être plus simple). Là il y a plein de solutions… je pense que le plus simple, c'est une fonction intermédiaire qui supprime les null avant de les envoyer à la fonction finale... array_remove le fait très bien.

CREATE OR REPLACE FUNCTION _final_median(NUMERIC[])
   RETURNS NUMERIC AS
$$
   SELECT _final_median_filtered(array_remove($1,NULL));
$$
LANGUAGE 'sql' IMMUTABLE;

CREATE OR REPLACE FUNCTION _final_median_filtered(NUMERIC[])
   RETURNS NUMERIC AS
$$
   SELECT AVG(val)
   FROM (
     SELECT val
     FROM unnest($1) val
     ORDER BY 1
     LIMIT  2 - MOD(array_upper($1, 1), 2)
     OFFSET CEIL(array_upper($1, 1) / 2.0) - 1
   ) sub;
$$
LANGUAGE 'sql' IMMUTABLE;

Non, la log postgres. Comme avant. On peut envoyer la log postgres dans le journal, mais debian et ubuntu ne le font pas par défaut.

Sinon si vous migrez d'oracle à pg, avec ora2pg, il me semble qu'il y a le choix entre migrer les chaînes vides d'oracle vers vide ou vers null dans PG. À vérifier

il vous faut

\pset quiet on

au début du script

Le select long peut aussi avoir empêché vacuum de faire son boulot sur le master, si hot_standby_feedback est activé (mais ce n'est certainement pas l'explication la plus probable de votre problème)

Vous êtes obligé de définir les 3 triggers. Par contre rien ne vous empêche, d'avoir une seule fonction que les 3 triggers appellent...

Juste un truc que je vois en lisant votre message:

En fait, tant que pg_stat_statements est en shared_preload_library, il fonctionne, que l'extension (qui permet d'interroger ce que pg_stat_statements collecte) soit installée ou non dans une base. C'est global à l'instance.

Par contre, je doute que ça soit lui, 20% d'impact serait énorme, par rapport à ce qu'on voit d'habitude (plutôt de l'ordre du pourcent). Malgré tout, si vous voulez en avoir le cœur net, redémarrez avec la librairie déchargée...