與在pgadmin中執行查詢相比，使用JDBC執行Postgresql查詢要花費更多時間

Question

我有一個存儲過程，帶有一個參數（參數）

讓我們稱之為x 。

我跑步的時候

select * from x('myParameter')

它會在4分鍾內完成。

現在，我嘗試在Java中執行相同的存儲過程，如下所示：

PreparedStatement statement = connection.prepareStatement("Select * from x('myParameter')");
org.postgresql.PGStatement pgstmt = (org.postgresql.PGStatement)statement;
pgstmt.setPrepareThreshold(1);
boolean usingServerPrepare = pgstmt.isUseServerPrepare();
System.out.println(usingServerPrepare);
statement.execute();

這大約需要26個小時才能完成。

我最初嘗試時沒有pgstmt.setPrepareThreshold(1); ，即prepareThreshold的默認值。 結果是一樣的。

然后，我嘗試使用“ set enable_nestloop false”作為存儲過程的第一行的Java程序，它在4分鍾內完成。

當我顯式強制服務器端准備好的語句時，我無法理解為什么查詢會更改執行計划。

我正在使用Postgres 9.4和Java8。我也在使用PGBouncer進行連接池。

我的查詢是-為什么JDBC會影響執行計划？ 有沒有辦法強制從Java程序觸發的查詢執行服務器端執行計划？

Answer 1

得到了解決方案：-存儲過程中使用了一個表，稱為“ tab1”。

當我們從PGAdmin / SQL窗口運行存儲過程時，早已創建/修改了tab1。

在使用Java的自動運行中，將在執行存儲過程之前幾秒鍾創建並加載/修改tab1。
在第一種情況下（ 從PGAdmin / SQL窗口運行存儲過程 ），在我們在PGAdmin中運行存儲過程時，tab1上的自動分析已完成，而在第二種情況下（ 使用java自動運行 ），在tab1上的自動分析尚未完成因為tab1剛剛被修改而開始或正在處理中。
與使用Java運行時相比，這使Postgres在從PGAdmin運行查詢時選擇了更好的計划。

總結-選擇了不同的計划，因為在第二種情況下，當我們運行存儲的過程時自動分析還沒有完成，從而導致查詢計划選擇不正確。