O planejador tem um problema com sua consulta, pois não pode avaliar o tempo de execução da função. Neste caso o planejador obtém o custo estimado de execução da função, que pode ser definido em
create function... ou alter function... . No entanto, se você tentar esta consulta:explain analyse select * from test(10);
você verá o tempo de execução muito mais realista.
Comparar:
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)
contra:
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)
Observe a semelhança dos dois últimos planos. Funções de tabela (funções que retornam um conjunto de linhas ou tabela como neste caso) devem ser chamadas em
FROM cláusula. Sob certas condições, eles podem ser embutidos. Leia mais:Inlining de funções SQL .
