Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t9Uik-00AX32-Cb for pgsql-performance@arkaria.postgresql.org; Fri, 08 Nov 2024 19:32:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1t9Uih-00Ci1P-Pc for pgsql-performance@arkaria.postgresql.org; Fri, 08 Nov 2024 19:32:36 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t9Uih-00Ci1H-FV for pgsql-performance@lists.postgresql.org; Fri, 08 Nov 2024 19:32:36 +0000 Received: from cloud.gatewaynet.com ([185.90.37.94]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t9Uie-000r20-Ea for pgsql-performance@lists.postgresql.org; Fri, 08 Nov 2024 19:32:34 +0000 Content-Type: multipart/alternative; boundary="------------QVMIIRr5M38bzItrPslW0vtH" Message-ID: Date: Fri, 8 Nov 2024 21:32:26 +0200 MIME-Version: 1.0 Content-Language: en-US To: pgsql-performance@lists.postgresql.org From: Achilleas Mantzios Subject: tds_fdw : Severe performance degradation from postgresql 10.23 to 16.4 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------QVMIIRr5M38bzItrPslW0vtH Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear All, we have hit a serious performance regression going from 10.23 → 16.4 as far as tds_fdw (MS SQL) FDW is concerned. To cut the long story short, I recreated the good fast “old” (pgsql 10) setup on the same vm as the slow “new” (pgsql 16). Here is the bug report on github : https://github.com/tds-fdw/tds_fdw/issues/371 All environment on the two pgsql clusters is shared (freetds version, tds_fdw, gcc, llvm). Only thing differs are pgsql versions. The speed on the old pgsql 10.23 is about 10 to 20 times higher than pgsql 16.4 . |Setting client_min_messages TO debug3 does yield identical output on the two systems. | The new pgsql 16.4 shows 100% CPU usage during the query execution. I know we are pretty much alone with this, but it would be very nice if anyone could help, see smth we are missing or guide us via the right path. --------------QVMIIRr5M38bzItrPslW0vtH Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Dear All,

we have hit a serious performance regression going from 10.23 → 16.4 as far as tds_fdw (MS SQL) FDW is concerned. To cut the long story short, I recreated the good fast “old” (pgsql 10) setup on the same vm as the slow “new” (pgsql 16). Here is the bug report on github :

https://github.com/tds-fdw/tds_fdw/issues/371

All environment on the two pgsql clusters is shared (freetds version, tds_fdw, gcc, llvm). Only thing differs are pgsql versions. The speed on the old pgsql 10.23 is about 10 to 20 times higher than pgsql 16.4 . Setting client_min_messages TO debug3 does yield identical output on the two systems.

The new pgsql 16.4 shows 100% CPU usage during the query execution.

I know we are pretty much alone with this, but it would be very nice if anyone could help, see smth we are missing or guide us via the right path.

--------------QVMIIRr5M38bzItrPslW0vtH--