Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Une question de "culture", je sais que les RAISE NOTICE représente un certains coût (je m'efforce de tous les supprimer après debug), mais qu'en est-il exactement ?
A t-on une idée plus ou moins précise du coût engendré et donc de la perte de performance ?
Merci d'avance.
Hors ligne
On peut simplement le mesurer
CREATE function sans_raise_notice() returns void
as
$$
begin
end;
$$
language plpgsql;
CREATE function avec_raise_notice() returns void
as
$$
begin
raise notice 'test';
end;
$$
language plpgsql;
\timing
select sum(series) from (SELECT generate_series(1,100000) as series, sans_raise_notice()) as tmp;
sum
------------
5000050000
(1 row)
Time: 145,166 ms
SET client_min_messages TO error;
SET
select sum(series) from (SELECT generate_series(1,100000) as series, avec_raise_notice()) as tmp;
sum
------------
5000050000
(1 row)
Time: 156,978 ms
SET client_min_messages TO notice;
sum
------------
5000050000
(1 row)
Time: 1211,444 ms
On voit donc qu'un raise notice qui ne se déclenche pas ne coûte quasiment rien (10ms sur 1 million d'itérations, soit 10 nanosecondes). Par contre un raise notice qui se déclenche coûte 1 seconde en tout, soit 1 microseconde à l'exécution.
Des RAISE DEBUG dans le code ne coûtent donc pas grand chose, par contre des RAISE NOTICE, qui par défaut vont être affichés, coûtent plus.
Dernière modification par Marc Cousin (18/05/2011 10:57:12)
Marc.
Hors ligne
Oui c'est vrai que je pouvais tester rapidement.
Donc effectivement, dans une fonction récursive, appeler un RAISE NOTICE peut vite devenir couteux.
Merci beaucoup pour cette démonstration.
Hors ligne
Si vous avez 1 million de niveau de récursions, oui… mais j'espère que non
Vous pouvez mettre un RAISE DEBUG pour votre récursion. Comme ça il ne sera affiché que si vous êtes en niveau debug. Ce qui ne sera pas le cas par défaut.
Marc.
Hors ligne
Pages : 1