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 1hQ4sM-0008Et-Ip for pgsql-performance@arkaria.postgresql.org; Mon, 13 May 2019 06:55:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hQ4sL-0003Fk-8b for pgsql-performance@arkaria.postgresql.org; Mon, 13 May 2019 06:55:53 +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 1hPwsQ-0007Kk-SY for pgsql-performance@lists.postgresql.org; Sun, 12 May 2019 22:23:27 +0000 Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hPwsI-0002E4-SC for pgsql-performance@lists.postgresql.org; Sun, 12 May 2019 22:23:24 +0000 Received: by mail-wm1-x333.google.com with SMTP id f2so11857575wmj.3 for ; Sun, 12 May 2019 15:23:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Dp6YNXDx8Ff914y6TItDv0gpIoSg6HBqLLD+OmU6fOM=; b=sUweloxHCO9LUujW2WY2FabWw+Mza7bd9IcQtnmV+rH2KtSDFNMhBKsTyabHZs7XKY E673XMY3TgBQxDdTG5tWla2J8hGhvAo49AuNGYPu84V3kSDzCTV1RDEQtTVkCS5hLnd1 qzufDD4EJ6ixgBQjXyO5xYgTCGsM6cWg99pO/FUB4R309VsS1VKKA9iF+bjdA36eC91V NNXyL5HoHvTOzrW1Fw1uaJzEDchTesPR9h71jHf38alWaaC7XUdzDdAWwwYQrgKe8+Ex dHJIPQPqyo8+7UvKrQDoSd6aB2uBiSP3M+O+msUKkhH6x5AjZYcoPx1L/lMIlxq/pft5 kF6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Dp6YNXDx8Ff914y6TItDv0gpIoSg6HBqLLD+OmU6fOM=; b=O+PgfpDd9tsFcCuAwm8FsmmnrQhWlLjyqhzY5eADy/MLYsd5AsMRzASragF9kGB9q9 QFI/wG1TKYlNIeAsyTE30OhJda87VsHBTqFTMuJvphjpRj+GdRmDmnCfkdDfjr4lAqcS H/T4d6CX0oeywQD4wodI/POb4L0qSuyOfFty3UIUJ900TJMIu/VLtILf2F/S+TbAnlUU N2HHXdRM5F1/tKSObZevgqL2EeJHbqF3WrsWjNXInUEG4T4lzN/1KT7KMWG6jG10p4BT /Gb4K4ycBPrWjxOUdU2TNTHCYGWAb2C2nrHyeGV8J0bLahyL0u1rbryXdmFlNlkgr2Hb ULUQ== X-Gm-Message-State: APjAAAXQrTpdpOuSNFyhyl3BgLbg3hCMpjH3vx/hkG7mNXneevTb9sMU xAX29PFjJQm5FTGOtuhT77flIGnb X-Google-Smtp-Source: APXvYqxuH24Bs+jEUQbIV8vqSc53DFXKol+JsIwLysmROXaClLHopxI+OshTvMMXXq/NN4ImL/nvAQ== X-Received: by 2002:a7b:c0d5:: with SMTP id s21mr8259924wmh.152.1557699795867; Sun, 12 May 2019 15:23:15 -0700 (PDT) Received: from [192.168.66.78] (p4FF43251.dip0.t-ipconnect.de. [79.244.50.81]) by smtp.googlemail.com with ESMTPSA id t18sm25317492wrg.19.2019.05.12.15.23.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 May 2019 15:23:15 -0700 (PDT) Subject: Re: Huge generated UNION ALL faster than JOIN? To: Tom Lane Cc: pgsql-performance@lists.postgresql.org References: <965737b8-0e86-9e61-e006-1f4d927e3c4f@googlemail.com> <23129.1557684481@sss.pgh.pa.us> From: Ancoron Luciferis Openpgp: preference=signencrypt Autocrypt: addr=ancoron.luciferis@googlemail.com; prefer-encrypt=mutual; keydata= mQINBE3Z7bUBEAC3ZYDTnxOiu0JWJR+6XzFQmJEVncGMehyuE9GBfyaNYnsNKmFITkubNVB9 tN/xgn5FJ9eg0WediTaWXigHNDDOPSNHZGaf1nHu0AQNOgpEyJETtX/A56PXQ82+VwoKCNUN v8+m5CJ8njWZlZMCVA3AcQ1vR2VRR6O0pzEVPDCDMutPytkRl+XrPoPhxMTVEmwM4jfWwmfI NgiOZnsueU78VW8Go1qTN20YdVOdVpbPWfyp8VIGYBNjEEefv5f/l+zt4Z+CQMmvunDUdaKY 85opNIMLqC3dDY0AQG+FpcDLhHWLcuGLmE+Ghiix0G3kX4QX/fH0/2KtVNdfnZtcpq+5rim0 E97PVQe4EixVD/DivpwvNMWqQ2GJlOCx52+J13ZSfe/63XpjL7TNqhR3wMnNuMidLMgLoH5z RtQ2FH9zeYlKgqMUkmwvEHVI+M4oQRE0rzgqx6xHbkPIFEov9ZziQVwCtct+Ja9ho/BXoe/T VIFVOGEp7DG12QSaiLILhzTRUkDXqa+BH9H4V2Hsv77nT2JQ7KO9pM5gb4wq4gtLFo7MMTUq jlqjD2vOm3NY3tg1s7HTggVNgGsWhh9JlNR3v9SRGckKVIIvwDxvzo+Z4iji2SLElWb9BWiH Xku5IEuWGTmC+nOzSvbSxTaC53JcppC5kKXj11N73uw5eR4s3wARAQABtDRBbmNvcm9uIEx1 Y2lmZXJpcyA8YW5jb3Jvbi5sdWNpZmVyaXNAZ29vZ2xlbWFpbC5jb20+iQI4BBMBAgAiBQJN 2e21AhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBzrR1GWXG7SN0DD/9qJR1Bsm52 W/T+XKQ0DApt3rCVgt9e5gvk4mUgtUIufIVOx3t/s2qw84VcSyNVclfoecLF0JdBWavobyCn JAIVkgGt0wGF6Kzsbiq7vlqDHDYiB7prvY4vj6bpmEQGYBBmWPG6/AVvBRJsvvaSGTqqdVth 4MYl43VxDZD+aVq52o0ROQAWyZC28kevTvRxusLuwZc4Q7HvOuAGNeD4aGLIgbOpyiS4mkC3 i2B++/cQ+zurzCWqCi1U/0sFXtwV2Qh6gjZK/TvZogTMUxjftZdvP49R5NrEB6AWx5ztp/RO 7Jy2j+Xm4OAteb5uGegzyoPKzr7B9O76GtfXLgLyZjpBIpuudosx+vJ9g7wuDHWXj7f5QKZQ PLqDO5SxI/Yi5tM4byag9/KZ7aHmeCXuAOnRTvKh6xMyB0fq6aPtpRlek4NcHWdT2SaR1y5K XxqWM/x7wLUyQo1lvjPTWX2MS70AjPJ5BdZzEjoA3zucT/ibu+CRjbyAOx5XwIBTnutj/+oI osslCFbMMj6n9NRoJidmy8q2nMYH+lMP1nTbdLCLesURVlTVLcMxIQhsjRZC/E6tu86C6rHB VrNjlUHkXHwJ9qQ3FbFOudqPUatYcfJSI7PmPbxWqNhcnVXlA1yndT7kAfWsmIxaJvDw09p5 dxkrNZi0LYoyLmMLImCb0yCHibkCDQRN2e21ARAAuQP7cntv+HFvl+3aUMZ68vTcV+0AfFfN DqZy6UYNbggIkuTtE5c5O88oBaJ/4idyAwzleb0Ess51xgYExv1zdxj61i+FfTOXEHhXp+uG Zk3mYVlp5juZwdEClrNkMTZehP6zvEvem5MkGGe3RBg7v4svg+xiaqaPMeN2Kj7KbObrlKcA F9A/4lRr5F0lH/RJaIaIUAgccVbRQdN1Z0JD6CU54sNlOCvkRqq1zNgmDSq/6WPs+WMkd0FT yMeyus9sPOmBrld4Wp6jHJSt7cYzq45F87b6oUPPVs4uSa1CN6IZZKk1rmQzuuFclTdw3Ari kjBKhFXe0gwsahPUYMOaICc62ivGKhHW/6HXh0JrPP9zqc/hMSY/fXffBXKAab4xnCA7/oUU 4W8/wD4qvq0w77i5bUJrHg+AhFEGDXWPfMCYjIE0oLTCYK696yhhVpVSFD8c3Uj1tSQERbBN 7qpDKGSOjRZyPLAH0yOAVgqteLkDhzwhqgwBhCXEOQAWqgvP2JI8cvbQYprG5uQnsS6TkYlq 1/nmmV+6HfMmitEp7siGaq0UmVZHBrGD+BQjuLkKPZ95YCSwc8xM/Y6viOIxvgisVRNXqo0r QW/FYXKnz0i7ZQTYE4Rad487mtd+eAcW1LhwBlM5dJRxx6Ee8dKkhjvQjap4MmghpNltULUF yGkAEQEAAYkCHwQYAQIACQUCTdnttQIbDAAKCRBzrR1GWXG7SOmfEACisSp8ZEfX6zVvzLNu YVXlvnQcd+w7VtN9+MMB3P9xZUku82/flaZTVvCbQ/kDRT9BrLdNcxM9dgt6Fgih49qN6+TI 2Atl+nBO9KtKaBc8wFs06VEEYkaIvtiS99KJO2wjQXKE1/Fj/HLKET62BctFFk5fgTdzHpxZ 2yovkQ+cPhkkyKpW7/UjFYn2Phpvg3KU1kcH/5oyGjRzCFTT0ERlyKWA/X/XxzX7+k2LVEh0 QzpuZbn/S0ldHDtP+fMoZZAHjVpWUu6A0zLYIHQkX/X4gkBvlWwvVuh27lDULJ8elrECyGOp 46G14r1t6bSnESm9W9AcvtG1pQQMv7zoHXJNgYew2cbkSxgBSjNNxnkUPIJdvX8Bel/iQzLr EXCaZ/myDJ4RNrzkvRBWdOWMvBkIV3yXogp6CyYzq5IaQgSIiv5Hr17ssuNR+FS5aZBocJru pCqLD/AdS3MZLBeRGmpDWkuj4uc4/4tLDIHcmCYia47FD2OuGSbLDz4BBeEmR37CkFsxIq6f eszCf1awGfZv7i0ddVFT3gtJTBoRE6VPkpcMrYaEjhtbrGI9PwB+7rNd4V9O6qPwV450KldB FwlHzOjWNRkfDUc3sgRB3QXlH3bVsHqUVBBTXf5YwqxeQtIRe/A7ICU3kLx8BKiUZXhOoTur jG7LftY+nte9Tt8CTQ== Message-ID: Date: Mon, 13 May 2019 00:23:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <23129.1557684481@sss.pgh.pa.us> 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 12/05/2019 20:08, Tom Lane wrote: > Ancoron Luciferis writes: >> One of the things consuming most of the time was an Index Only Scan >> executed millions of times. And on top came the Nested Loop which >> finally reduced the rows but also took a lot of time to do so. > >> Explain plan: https://explain.depesz.com/s/4GYT > > The core problem you've got there is the misestimation of the join size: > > Nested Loop (cost=0.71..0.30 rows=72,839,557 width=33) (actual time=19,504.096..315,933.158 rows=274 loops=1) > > Anytime the planner is off by a factor of 250000x, it's not going to end > well. In this case, it's imagining that the LIMIT will kick in after just > a very small part of the join is executed --- but in reality, the LIMIT > is larger than the join output, so that we have to execute the whole join. > With a more accurate idea of the join result size, it would have chosen > a different plan. > > What you ought to look into is why is that estimate so badly off. > Maybe out-of-date stats, or you need to raise the stats target for > one or both tables? > I thought so as well and that's why I started investigating, but after creating my own data set and a final analyze of both tables I ended up with similar difference in estimation vs. actual: https://explain.depesz.com/s/R7jp Nested Loop (cost=25.17..514,965,251.12 rows=27,021,979 width=56) (actual time=0.568..5.686 rows=274 loops=1) ...but this was fast due to the Merge Append being used and pushed-down LIMIT. >> My question now is why can't the optimizer generate a plan that in this >> case does 114 loops of "events" scans instead of a million loops on the >> "subscription_signal"? > > I don't see any "events" table in that query, so this question isn't > making a lot of sense to me. But in any case, the answer probably boils > down to "it's guessing that a plan like this will stop early without > having to scan all of the large table". > > regards, tom lane > Yes, Timescale extension is mangling the partition names quite a lot. I wonder if it would be possible to hold the result of the estimated smaller reference data (114 subscription_signal.signal_id entries in this case) in a VALUES list and then use that to filter the table with the larger estimate instead of looping over. Cheers, Ancoron