PostgreSQLのパフォーマンス-SELECTとストアド関数

プランナーは、関数の実行時間を評価できないため、クエリに問題があります。この場合、プランナーは関数の推定実行コストを取得します。これは、create function...で定義できます。 またはalter function... 。ただし、このクエリを試してみると：

explain analyse select * from test(10);

実行時間がはるかに現実的であることがわかります。

比較：

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)

対：

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)

最後の2つの計画の類似性に注意してください。テーブル関数（この場合のように行またはテーブルのセットを返す関数）は、FROMで呼び出す必要があります。 句。特定の条件下では、インライン化できます。

続きを読む：SQL関数のインライン化 。