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 1huXR9-000844-5q for pgsql-performance@arkaria.postgresql.org; Mon, 05 Aug 2019 07:29:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1huXR8-0006l0-2V for pgsql-performance@arkaria.postgresql.org; Mon, 05 Aug 2019 07:29:42 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1huXR7-0006gd-L4 for pgsql-performance@lists.postgresql.org; Mon, 05 Aug 2019 07:29:41 +0000 Received: from mout.kundenserver.de ([212.227.17.24]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1huXR4-000363-Ob for pgsql-performance@lists.postgresql.org; Mon, 05 Aug 2019 07:29:40 +0000 Received: from [10.8.0.6] ([185.40.248.10]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MuDsZ-1iCkfj1K6H-00ua7T for ; Mon, 05 Aug 2019 09:29:34 +0200 Subject: Re: Strange runtime partition pruning behaviour with 11.4 To: pgsql-performance@lists.postgresql.org References: <29b2f4c6-987b-d364-2e1d-bbd479d06da2@gmx.net> <9c55d578-bb70-d439-6450-abc291957ec3@gmx.net> <84f4f721-2c1b-6a31-f10e-204af2c0e624@a-kretschmer.de> <14075.1564848353@sss.pgh.pa.us> From: Thomas Kellerer Message-ID: <7cbc11eb-9c35-f844-ce9f-5820bf2a3a5c@gmx.net> Date: Mon, 5 Aug 2019 09:29:33 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 In-Reply-To: <14075.1564848353@sss.pgh.pa.us> Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:KAxdKjt38J+un3PEMv/QFsMKHCoGtMF6epaGk9yk4i/GpDV+3p7 EZd/1r1KNX5An40dLUSqMfyeZt6+usXukMUt52boXczduZb5O/l8hLNcIKLdS6QmkPAeLwP 8PyqcKbL/q3duD+bKWAh8KuATdJzYuv3GEQ8s3LkjpQx76p/8ekJrEZxxJNXq5gXeHOWP9H WxGMcsBfARi9eG+h5wcsg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Gartk52Bakg=:Tiau+hjDuwIONMGSXgMKRU tbx8FRGGlXLcNf3ySZ/vlvut1IfL2m63ckNZcQsSxUN9a+iU7shC3njRUPyCaCkgMFQRf5+9m C2CUjAKPmbj60OUOGpSsCyxKhVoTAX2YynCZCBki1Bri0GAdNq0PJTaIguAfAiYQvPUkAh0Q/ ia6fhscmQG0JZv+tNrLqszu+NaJFsSMmk3kd8FUekdeJArXYK0UrbUXjH+7zuo6CDUPLTogjV xSGM02n1+ixNMbWhnkTI8XqhA0T405sVcSmnSbaREnd9ISLAJ7pEVIWlpzx4nMpmzH+qGQzs8 1+C8mX0F+TEBcVKmUoRU7fN498+mTeFcyorQ6iwiR3gkJcmX0YxfttAaxrMKN2igSITNxWwZq 45HwOq5TqqJpHsHbXA+fqbiUsFJYGxX9RKCbuYGIJNt4Bqurax81CSTiPTP7fL9K5XtyWYyJO jOw7m+AW/eJ6k3mNRDBbJP6uQMog0r8+mlGE9GArmqBDh6f/XvNJ+1I5Dr/e0H4jLpRzFpsmo oxpE7c4A3w+pf97ILfLnJPbL8cioiHuPZ5WeDA7TuFdbFplV+EdAt4eCmMXBaRu1zhw+pG1cC rXPIBV3Zei8uXprOTWQUjxdoSkSWTKlma4N6yfFBsbkZdjj6hIm9eLiGUtyKg20XL3VJ/HghC dzhXemaeskoBOeqsQOlC7W2MqXa9Oz3MBU8CX3zD+SUqFnL4Mmb4MREapr+l5LVG9ZYNICz+m urL7Bi3leZ0a7wpGMElQspuDyaA4lDD/92/fc3wMYCtkZysXCil/mquGbmE= List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Tom Lane schrieb am 03.08.2019 um 18:05: > Yeah, I get the same plan with or without ANALYZE, too. In this example, > having the ANALYZE stats barely moves the rowcount estimates for > foo_bar_baz at all, so it's not surprising that the plan doesn't change. > (I do wonder how Thomas got a different outcome...) I don't know why either ;) I am using a JDBC based SQL tool to run that - I don't know if that matters. I just tried this script with Postgres 12 beta2 and there I do not get the initial plan with "never executed" (so the same behaviour as everybody else seems to have). If the reason why my initial plan is different than the "analyzed" plan lies in the configuration, I am happy to share my postgresql.conf if that is of any interest. Thomas