Le planificateur a un problème avec votre requête car il ne peut pas évaluer le temps d'exécution de la fonction. Dans ce cas, le planificateur obtient le coût d'exécution estimé de la fonction, qui peut être défini dans create function... ou alter function... . Cependant, si vous essayez cette requête :
explain analyse select * from test(10);
vous verrez que le temps d'exécution est beaucoup plus réaliste.
Comparez :
test=# explain analyse select test(1000);
QUERY PLAN
------------------------------------------------------------------------------------------
Result (cost=0.00..5.25 rows=1000 width=0) (actual time=0.830..1.220 rows=1000 loops=1)
Planning time: 0.038 ms
Execution time: 1.250 ms
(3 rows)
contre :
test=# explain analyse select * from test(1000);
QUERY PLAN
----------------------------------------------------------------------------------------------------------------
Limit (cost=0.00..37.42 rows=1000 width=4) (actual time=0.006..0.124 rows=1000 loops=1)
-> Seq Scan on test_table (cost=0.00..2560.28 rows=68428 width=4) (actual time=0.005..0.102 rows=1000 loops=1)
Planning time: 0.130 ms
Execution time: 0.144 ms
(4 rows)
test=# explain analyse select * from test_table limit 1000;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------
Limit (cost=0.00..37.42 rows=1000 width=269) (actual time=0.009..0.118 rows=1000 loops=1)
-> Seq Scan on test_table (cost=0.00..2560.28 rows=68428 width=269) (actual time=0.008..0.097 rows=1000 loops=1)
Planning time: 0.076 ms
Execution time: 0.151 ms
(4 rows)
A noter la similitude des deux derniers plans. Les fonctions de table (fonctions qui renvoient un ensemble de lignes ou une table comme dans ce cas) doivent être appelées dans FROM clause. Sous certaines conditions, ils peuvent être alignés.
En savoir plus :Inlining des fonctions SQL .
