Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1joPpH-0000Lb-QQ for pgsql-admin@arkaria.postgresql.org; Thu, 25 Jun 2020 11:13:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1joPpG-00083I-NW for pgsql-admin@arkaria.postgresql.org; Thu, 25 Jun 2020 11:13:50 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1joPpG-00083B-Fj for pgsql-admin@lists.postgresql.org; Thu, 25 Jun 2020 11:13:50 +0000 Received: from mx1.vit.de ([45.9.85.12]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1joPpE-0001kk-63 for pgsql-admin@postgresql.org; Thu, 25 Jun 2020 11:13:49 +0000 Received: from localhost (localhost [127.0.0.1]) by mx1.vit.de (Postfix) with ESMTP id F1D6A23BA1 for ; Thu, 25 Jun 2020 13:13:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mx1.vit.de Received: from mx1.vit.de ([127.0.0.1]) by localhost (mx1.vit.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO2d-dT68UlH for ; Thu, 25 Jun 2020 13:13:46 +0200 (CEST) Received: from nuc4475.vit.de (nuc4475.vit.de [172.16.6.175]) by mx1.vit.de (Postfix) with ESMTP for ; Thu, 25 Jun 2020 13:13:46 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nuc4475.vit.de (Postfix) with ESMTP id 9C369CE7543 for ; Thu, 25 Jun 2020 13:13:46 +0200 (CEST) Subject: Re: Performance of SELECT directly and from application To: Pgsql-admin References: <404eece7-44b3-bbb4-177a-ff955d10e7e6@vit.de> <9dda6f8fa24bb80c7456a8439cba0b4adf2b8ae4.camel@cybertec.at> From: Jessica Holle Message-ID: <7ee1fb6b-b1d2-f69b-7a28-e37c32c696fc@vit.de> Date: Thu, 25 Jun 2020 13:13:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <9dda6f8fa24bb80c7456a8439cba0b4adf2b8ae4.camel@cybertec.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: de-DE List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Thanks for this advice. We found out, that application use the following paramters: set max_parallel_workers_per_gather to 4; set min_parallel_table_scan_size = '1MB'; set parallel_setup_cost = 10; set parallel_tuple_cost = 0.001; Now they are using standardparamteers and they have restart Wildfly with deleting tmp and -surprize- as fast as before. I'm not allowed to post the plan until it is anonymized. Until now thanks for helping. Kind regards, Jessica Am 24.06.20 um 08:14 schrieb Laurenz Albe: > On Wed, 2020-06-24 at 07:00 +0200, Jessica Holle wrote: >> we use PostgreSQL 12.3.1 and have a little bit trouble with performance. >> When the statement comes from the application (wildfly) duration is >> about 24982.819 ms. When I do the statement directly with psql duration >> is 967.773 ms. >> Duration from Wildfly is known becaue we use in postgresql.conf >> "log_min_duration_statement = 5000". There I see, that from application >> are 3 variables used. >> Is there any idea why this can happen or a hint to solve this issue? > Try using "auto_explain" to get EXPLAIN (ANALYZE, BUFFERS) output for the slow > execution. The comparison of these two execution plans would be instructive. > > Does the application set any parameters? Does it use a cursor? > > Yours, > Laurenz Albe -- *************************************************************** Jessica Holle rzv - Rechenzentrum Verden GmbH Heinrich-Schröder-Weg 1, 27283 Verden (Germany) Tel. +49 (0)4231-955 377; Fax. +49 (0)4231- 955 333 www.vit.de Amtsgericht Walsrode HRB Nr. 120138 Geschäftsführer: Dr. Reinhard Reents Vorsitzender des Aufsichtsrates: Anton Fortwengel ***************************************************************