Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f8XEH-0005q1-74 for pgsql-performance@arkaria.postgresql.org; Tue, 17 Apr 2018 20:29: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 1f8XEF-0006Zu-P7 for pgsql-performance@arkaria.postgresql.org; Tue, 17 Apr 2018 20:29:27 +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_SHA384:256) (Exim 4.89) (envelope-from ) id 1f8XEF-0006Zl-D2 for pgsql-performance@lists.postgresql.org; Tue, 17 Apr 2018 20:29:27 +0000 Received: from mail-wr0-x22b.google.com ([2a00:1450:400c:c0c::22b]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1f8XEA-0006Z2-Me for pgsql-performance@lists.postgresql.org; Tue, 17 Apr 2018 20:29:26 +0000 Received: by mail-wr0-x22b.google.com with SMTP id v24so21921731wra.8 for ; Tue, 17 Apr 2018 13:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=2U660BZDKz2nJlPBPelNRs2p8OiYkovZzzkBdVqISHs=; b=xyGUH5aCA/RF9+x7jctI3zY9Oyu5VVcndVNyEG3PXUpHFHDs+oHXS7gtYTGltpHrjX qHwa5uDx0/BGR+hsq7tVKe0YD3vSQXE+v4NCH0wNPa4WUiL4VPo0pFu3cff6cR8pixGn GEn6fGfmQ4LAbi7laGXCJEVQJOwwWUs7bv+A+YqOCyjCYNYg9jM+hhRWYwlnS5kyu4Yr 7jOXBSPlk83oZw6yxj8txssW8TQmmKnlygUUKY2FtaKOq7g0zgXji4U5jYcpUw+1e7Il wEE/CTBX9jw7b9DrBy5CilECEaORWZNx50s2APbmv2K4VkA39LPm0hbi8jiVORTwMBsk RglQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2U660BZDKz2nJlPBPelNRs2p8OiYkovZzzkBdVqISHs=; b=X1duIyTqI6FR/wxoi6peUrX2lfvAuz/RuG6xEenRo3ciemRkakRwB9JacM/td7ydji RR9Di5hpDXY7EUJncmOXD3e6hOfhHYizPKrp+lGN3eIV3vRxvcvKYpS5LymWHijZAGJP K6kLlElREt7IzZ9ovt7RxLVOyWFNWnxCRkd+0acSwdjNLGgbqS7OuS+LrTQUim20PCCG SXxM+euMNqGIPHmdSqrseKPjuT8TZQzaaw0mjG0q07mUM/7mKsO4c3Vh7MJIjLb9gT1h sTuVk2A4S+1RnOhIFN/mobqwpPqHZxQMaAV2XLHi/7uQM+L2NE+/TbkG8QoYvr0StN+2 Vt/w== X-Gm-Message-State: ALQs6tBiE0PPBTrAn81H+5lNY9Ul7PQPzz0UYmUjVBrwJu98Zur1Gmvw BE6ftREieRRtUC25K9UJ2C8vyb5hW1wEVt9Py2JdGcMjXXA7NSp+6k6Q0WSAIRPLdnxKX7B+nVg vL5aQ+n/rTQyH4PgZFWhBoMCGW1J4PzfPVgKlAJT/DeO3FTOiOj9SrcNfpWwK3A6nFL/z2lXvb3 h7/Xvp4VvLEzGrg38PkhPUzw== X-Google-Smtp-Source: AIpwx49yYmFYIibUIN5Cw1U3sypgC/iGK4Qh1PjBCoJvlVQFbwOKs/FXIEKCc3C2/3OuhEXI5lNDtw== X-Received: by 10.223.171.198 with SMTP id s64mr2781003wrc.66.1523996960592; Tue, 17 Apr 2018 13:29:20 -0700 (PDT) Received: from [10.137.2.19] (ip-78-102-97-226.net.upcbroadband.cz. [78.102.97.226]) by smtp.gmail.com with ESMTPSA id m35sm19538280wrm.59.2018.04.17.13.29.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Apr 2018 13:29:19 -0700 (PDT) Subject: Re: Unexplainable execution time difference between two test functions...one using IF (SELECT COUNT(*) FROM...) and the other using IF EXISTS (SELECT 1 FROM...) To: Hackety Man , Pgsql Performance References: From: Tomas Vondra Message-ID: Date: Tue, 17 Apr 2018 22:29:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 04/17/2018 05:43 PM, Hackety Man wrote: > > > On Tue, Apr 17, 2018 at 10:23 AM, Tomas Vondra > > wrote: > > > > On 04/17/2018 04:01 PM, Hackety Man wrote: > > ... > Right.  I was more wondering why it switched over to a generic > plan, as you've stated, like clockwork starting with the 6th > execution run. > > > That's a hard-coded value. The first 5 executions are re-planned > using the actual parameter values, and then we try generating a > generic plan and see if it's cheaper than the non-generic one. You > can disable that, though. > > > > So on that note, in the planner's eyes, starting with the 6th execution, > it looks like the planner still thinks that the generic plan will > perform better than the non-generic one, which is why it keeps using the > generic plan from that point forward? > Yes. The point of prepared statements (which also applies to plpgsql, as it uses prepared statements automatically) is to eliminate the planning overhead. So we try planning it with actual parameter values for the first 5 plans, and then compare it to the generic plan. > Similar to the parallel scans, any chance of the planner possibly being > enhanced in the future to come to a better conclusion as to whether, or > not, the generic plan will perform better than the non-generic plan?  :-) There's always hope, but it's hard to say if/when an enhancement will happen, unfortunately. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services