Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gdKxF-0002Kf-Qm for pgsql-performance@arkaria.postgresql.org; Sat, 29 Dec 2018 20:11:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gdKxC-0001AU-25 for pgsql-performance@arkaria.postgresql.org; Sat, 29 Dec 2018 20:11:26 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gdKxB-0001AM-R2 for pgsql-performance@lists.postgresql.org; Sat, 29 Dec 2018 20:11:25 +0000 Received: from n3.nabble.com ([162.255.23.22]) by magus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gdKx4-0000GI-Mt for pgsql-performance@postgresql.org; Sat, 29 Dec 2018 20:11:25 +0000 Received: from n3.nabble.com (localhost [127.0.0.1]) by n3.nabble.com (Postfix) with ESMTP id 48705111A8FB3 for ; Sat, 29 Dec 2018 13:11:16 -0700 (MST) Date: Sat, 29 Dec 2018 13:11:16 -0700 (MST) From: Jim Finnerty To: pgsql-performance@postgresql.org Message-ID: <1546114276294-0.post@n3.nabble.com> In-Reply-To: References: Subject: Re: Gained %20 performance after disabling bitmapscan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk changing parameters can have surprising effects. fyi, I tried disabling bitmapscan and running the 113 queries (iirc) of the Join Order Benchmark against them. Several improved. Here the 'Baseline' is the best previously known plan, and 'Baseline+1' is the plan with enable_bitmapscan = false. Notably: NOTICE: Baseline [Planning time 90.349 ms, Execution time 12531.577 ms] NOTICE: Baseline+1 [Planning time 81.473 ms, Execution time 7646.242 ms] NOTICE: Total time benefit: 4894.211 ms, Execution time benefit: 4885.335 ms shaved 4.9s off a 12.5s query, and: NOTICE: Baseline [Planning time 198.983 ms, Execution time 2715.75 ms] NOTICE: Baseline+1 [Planning time 183.204 ms, Execution time 1395.494 ms] NOTICE: Total time benefit: 1336.035 ms, Execution time benefit: 1320.256 ms gained nicely in percentage terms, and: NOTICE: Baseline [Planning time 91.527 ms, Execution time 12480.151 ms] NOTICE: Baseline+1 [Planning time 84.192 ms, Execution time 7918.974 ms] NOTICE: Total time benefit: 4568.512 ms, Execution time benefit: 4561.177 ms also had a nice 4.5s+ improvement, among other plan diffs. This just shows that when you inject a new planning constraint into a workload, at least some of the plans will probably get faster. In this case a few of them got significantly faster either in absolute terms or in percentage terms. Unsurprisingly, the great majority got slower. /Jim ----- Jim Finnerty, AWS, Amazon Aurora PostgreSQL -- Sent from: http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html